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.
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
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