You are here: Foswiki>Applications Web>AppTests20162018Sis18BeamTime (13 Apr 2020, JuttaFitzek)Edit Attach

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?
    • UPDATED 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.
    • UPDATED 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.
      • TODO 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 (UPDATED 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

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) UPDATED 4. Device-Adapter-based (without consistency check)
Sketch
  • UPDATED 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?)
  • UPDATED 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
      • TODO 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
Topic revision: r9 - 13 Apr 2020, JuttaFitzek
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback