Requirements for SIS18 beam time 2016 / 2018

Beam time 2016

Current approach

• Use "old" version of ParamModi with cycles
• Use current version of LSA (core) with legacy-mode of DriveService (utilizing SettingAwareDevices)

Risks

• Unsure if "old" SettingAwareDevices will work properly "out of the box" (works at CERN, but to be verified for GSI)
• Some equipment might have changed behavior / interface since last machine experiments with LSA without notification (as usual, it seems)
• Something in frameworks and / or middleware for using DeviceAccess interface might have changed (Raphael found a bug recently)

Mitigation measures

• Use DeviceAccess mock device(s) to make sure that drive values are correct / legacy mode works
• Conduct drive tests with actual devices as early as possible

Status

• Raphael sucessfully revived device access mock for LSA code and set up a "virtual SIS18"

Next steps

• Prepare concrete test approach for legacy mode and carry out tests (proof of concept)
• Which database? -> Copy Current Dev
• Console configuration -> Check that it still works (shell/32-bit/webstart/skript)
• SIS Modi MD?
• Ramped devices from Peter to test ramp with intermediate flattop.
• DataMaster/Pulszentrale does it work?

Beam time 2018

Current approach

• Switch to new version of ParamModi
• Use LSA with DeviceAdapters
  • Pro: legacy code for SettingAwareDevices can be removed in LSA common core (if CERN agrees to do so, too)
  • Pro: SettingAwareDevices most probably wouldn't work with patterns. Is it worth checking?
  • Con: It might take quite some effort to support ramped devices that have not been updated to SCU/FESA yet (but the same might be true for making SettingAwareDevices "pattern-compatible")
    • Jutta clarified that all ramped devices (which are of type FG for Function Generator) will definitely be replaced by SCU/FESA for the 2018 beam time.

Risks

• LSA does not support non-multiplexed settings
  • There is a workaround in place that isn't pretty, but works. Normally the FESA core rejects everything but a null selector for non-multiplexed properties. FESA devices can be configured to deactivate this check and ignore the selector. Setting values will be sent more than once if there are settings in more than one beam process, though. The model has to check that they're consistent. Also, we have to check that FESA developers set that flag.
• LSA does not support sequence-multiplexed settings
  
  • There is a workaround in place that isn't pretty, but works for scalar values: We just send the value n times (where n is the number of beam processes in a sequence). The model has to check that they're consistent. This does not work for ramped devices, though.
  • For ramped devices, the function "chunks" that belong to the same sequence have to be combined into one function and then sent to the front-end as a whole.
    • Jutta clarified that all ramped devices (which are of type FG for Function Generator) will definitely be replaced by SCU/FESA for the 2018 beam time. So we don't actually need to combine functions as all ramped devices will be beam-process-multiplexed.
    • State again that we rely on that commitment during retrofitting workshop on 15th of February.
  • Once the new selector (C.T.S.P) is implemented and rolled out ( will be included in the next FESA release in February 2016) : Make sure that sequence-multiplexed devices accept a selector that has a beam process index specified (and that it is ignored).
    • Verify with Alexander Schwinn that this behavior has been agreed upon. Verified. Sequence-multiplexed devices will ignore the process index portion for set and get operations. They will adhere to the process index for subscribe if it has been specified, though.

Requirements

• Scheduling sub-chains multiple times
  • Clarify when exactly we will need this
  • Concept & realization of how to handle start times for beam processes in chains
• Drive/FESA Transactions
  • First all devices should receive the settings, if no error occurs some kind of 'commit' event should be sent and the settings will be resident in a consistent way.
  • CCT: Udo + Ludwig
  • Fesa: Solveigh + Alex
  • Do we have a commit 'delay'? Do we have devices that need some time to swap to new commited values or to make them 'active'?

Potential solutions

• LSA does not support sequence-multiplexed settings

	1. Model-based (additional particle transfers)	2. Model-based (no additional particle transfers)	3. Device-Adapter-based (with consistency check)	4. Device-Adapter-based (without consistency check)
Sketch	Create dedicated beam processes that contain combined functions (maybe also scalars) in addition to "normal" beam processes Jutta clarified that all ramped devices (which are of type FG for Function Generator) will definitely be replaced by SCU/FESA for the 2018 beam time. "Sequence beam processes" contain settings for actual hardware in a separate particle transfer, "normal" beam processes just for virtual devices Combination is carried out in dedicated make rule(s)	Same as 1, but without additional particle transfers	Combination is carried out in device adapter	Same as 3
Pros	Does not require new features in framework Combination is easily verifyable because combined function is a setting	Same as 1, but potentially less clutter	No additional effort for the modelers Model is not cluttered	Same as 3, but does not need fetching of additional settings from the database
Cons	More effort for modelers Clutters the model Needs additional particle transfers (potentially a lot of them?) If combining functions is not necessary, creating seperate beam processes just to check that scalars contain the same value and not send them multiple times seems like overkill	Same as 1, but we would also need to allow multiple beam processes per particle transfer at the same time (which we planned to forbid)	Combination is not traceable for the user DeviceAdapters (in contrast to SettingAwareDevices) are called per DrivableContext (not per StandAloneContext), so they cannot easily combine settings from multiple beam processes Settings would have to be fetched from the database which could lead to performance issues Hanno: Look into code if check could be done elsewhere / settings from other BPs in sequence could be provided somehow Some hacky mechanism would be needed to not load settings from database / drive them to the front-ends for every beam process in a sequence (e.g. only do it for the first BP)	Combination is not traceable for the user Cannot provide a consistency check because it just sends the setting value from one of the beam processes, relying on the model that the one picked (e.g. beam process with PROCESS_IDX = 1 in every sequence) is correct for the whole sequence

Next steps

• Discuss potential solutions identified so far
• Brainstorm for additional potential solutions
• Estimate effort for implementation
• Pick one potential solution and prototype it
• Discuss additional requirements / risks