Initial Meeting on Project Planning for the new UNILAC Beam Loss Monitoring System

Date: 2024-12-05

Participants: Michał Dziewiecki, Peter Gerhard, Tobias Habermann, Hanno Hüther, Karim Laihem

Minutes: Hanno Hüther

Michał introduced the basic ideas and design principles behind (the hardware-layer of) the new BLM system for UNILAC. He frequently referred to the block diagram from the BLM system's documentation (shown below), explaining how it is comprised of inputs, counters and outputs configured by datasets and structured into groups.

Michał specified that a total number of 54 trafo inputs, 12 input gates, 128 counters, 6 outputs, 32 datasets and 16 groups are available per crate. Currently, he is planning for 2 crates to be installed, but if that would prove insufficient, it might be possible to install 3 crates depending on available rack space. Peter stated that in order to be compatible with the current chopper control hardware, 4 outputs are required for beam loss signals and an additional 4 outputs for profile grid protection signals, which would mean that at least 2 crates are required.

As far as it can be determined after a quick and rather superficial assessment based on the information provided, the new beam loss monitoring system hardware seems to be appropriate in principle for replacing the existing legacy hardware. However, there is still some concept work to be done regarding assignment of the individual components (inputs, counters, outputs, groups) to ensure that it actually delivers the required functionality. A more reliable statement can be made after a proposal for concrete configuration has been established. This requires contributions from UNILAC and/or beam diagnostics experts. (PG: For the moment I do not see a requirement for BD experts)

Hanno: Ask Michał for a link to the specification for the new beam loss monitoring hardware

Additionally, depending on how the grouping mechanism in the new beam loss monitoring system hardware will be utilized (probably also considering assignment of timing events within the ECA units of each crate), one might also have to come up with a concept on how to disable beam loss monitors that are irrelevant for a certain beam / BPC / Virtual Accelerator (i.e. must not lead to a beam loss being reported by the system) depending on the currently used beamline. As an example, Peter explained that when sending beam through the transfer channel to TKD, beam loss monitors further down the transfer channel (beyond TKD) going to SIS18 must be ignored (see also the beamline diagram for UNILAC), even though they are not separated timing-wise (at least when looking at the Pulszentrale's timing sections; this would be different if one relied on White Rabbit-specific timing groups). (PG: so far, the new beam loss monitoring does not care for timing at all, but relies solely on the gate inputs) In the legacy system, this is achieved by setting (PG) a special maximum threshold value of 18000nC for the individual beam loss monitors to be ignored. However, this mechanism is not compatible with how the LSA settings management system works (and currently achieved through additional logic in the Sequencer service (PG) which provides data supply in parallel to LSA), so other options to handle this should be investigated. PG: ... with special attention to the safety of the whole process.

Karim reported that implementation of the FESA class(es) that will be required to transfer threshold settings from LSA to the new beam loss monitoring system hardware has not been started yet. Before implementation can commence, additional concept work is required (based on the already mentioned configuration concept for the hardware layer) to determine which deploy units and nomenclatures the FESA layer shall provide. One option that has been discussed would be to provide one deploy unit / nomenclature per transformer pair, which should roughly resemble how the legacy system works on the DeviceAccess-layer. This would, however, imply that the FESA layer provides an abstraction between the centralized hardware of the new beam loss monitoring system hardware and the transformer / beam loss monitor devices distributed along the beamline. Implementing such an abstraction layer would probably prove to be non-trivial and the resulting effort should be considered for project planning. Karim also indicated that he would require additional information from both beam loss monitoring system hardware and UNILAC / beam instrumentation experts in order to move forward.

The current goal for a production release of all components (hardware / front-end / machine model layers) required to actually use the new beam loss monitoring system for UNILAC has been set for the 2026 beam time. According to the current state of strategic project planning for the Injector Controls Upgrade project, this would mean that the new beam loss monitoring system as a whole should be ready for integration testing by October 2025. This seems achievable in principle, but rather ambitious in practice. (PG) For time being, no strict deadline for the replacement of the legacy system could be identified. Also, the role of a project lead for the overall system seems not to be staffed currently.

Hanno/Peter: Ask Ralph about the strategic planning for the project

Now that a basic common understanding of the project's status, deliverables and open issues has been achieved, a follow-up meeting shall be scheduled in early 2025 to discuss how to proceed with the project.

Hanno/Peter: Invitation to follow-up meeting

Remarks (Peter, after the meeting) without knowledge and questioning of the specs:

• clarify coordination of BLM and cups, to me this is unclear even for the legacy system; maybe this is no problem because there are no cups within the monitored areas of the UNILAC so far?
• proposal tbd for adding some safety and solve the problem of deactivating unnecessary/unwanted loss monitors:
  • LSA provides thresholds for all monitors within context AND transferline
  • Front End contains look-up table (may be hardcoded or generated somehow) of all available monitors and their transferline memberships; this table has to be supervised and maintained by the person in charge of the hardware together with its counterpart for the front end, because they know what monitors are actually connected to the system
  • this enables the Front End to 1) cross-check the monitors which have been provided thresholds by LSA for a certain context with its own list of monitors attached to the corresponding transfer line, and 2) disable the monitors which are not part of the transfer line
• how to check/monitor that the connected monitors (i.e. beam transformers) are live?