Device-related applications

The following notes have been taken during the workshop or have been derived from the cards written during the workshop. As the workshop was based on the attached introduction the contained information is not listed here again.

Device Control and MASP UI

Motivation to think about MASP UI and Control Device

• Avoid double development efforts
• Better user guidance

Usage

Device Control

• Used during commissioning
• Working through the beam line
• Known commissioning procedure: Ensuring that everything is fine (green).
• Application is perceived as known by operators
• Used for 'daily business'
• Table of beam instrumentation devices is used 80% of the time.

MASP UI

• There is a connection between using BSS Control and MASP UI. When inspecting the MASP status in BSS Control and discovering a bad MASP Status, MASP UI is launched to see all the details.
• MASP UI is not necessarily a 1:1 mapping of the MASP functionality into a user interface. The idea of the application is to provide handling of chain-preventing statuses.

Differences

• Device Control is used during commissioning. MASP UI is used during normal operation.

Status display in Device Control

• Attendess perceived no big differences in the accuracy in which the device status is displayed by Device Control compared to MASP UI.
• Currently Device Control displays way more devices than MASP UI
• Should AppApplicationDeviceControl display device statuses in the future?
  • Don’t change
  • In the same way as MASP UI does it (using MASP)
  • Don’t display a status at all

Suggestions MASP UI

• Improve findability of devices. Introduce different perspectives like equipment group.
• Display detailed status in a similar way as Device Control
• Provide matching Sequencer tasks
• Different possible way to handle a bad status in the future:
  • Users start in MASP to identify the device with bad status
  • Starting from there are multiple way to handle the problem:
    • Handle the problem completely in MASP
    • Open AppApplicationDeviceControl for certain problems or detailed status analysis.

Results

• We haven’t had a real beam time so far. All hard requirements have been met. Now it’s time to make the next step and start to improve the system. We’ll conduct the next beam time and reevaluate.
• Improved consultation between MASP UI and Device Control development teams is desirable and planned. Double development efforts should be avoided.
• Device Control development will be continued similiar to the existing approach for now. Device Control is questionable in the long run though.
• No urgent need to change the way the status is acquired in Device Control.

General remarks

• Some attendees assumed that seeing the status of a device isn’t possible as timing is required. Actually timing isn’t required to read the status. Reading status should work in MASP UI as well as in Device Control by selecting a certain context that defines the area to observe.
• Masking devices is now possible in MASP UI

Set-actual comparison

• Different perspectives:
  • Whole beam line
  • Whole course of time (filter, zoom)
• Display complete course of time based on selected device-parameters
• It must be considered that actual values must be acquired continuously. Problematic actual values located between beam processes would be missed otherwise.
• Ramped as well as pulsed devices should be supported
• In the future settings of type function will be used in transfer lines. Currently only scalar values are used.
• In the future when everything works as expected MASP should consider the check performed on frontend-level and prevent chain execution.
• An action on the device in MASP UI would open a visualization of the ramp
• In the future set-actual comparison on frontend level should be performed based on LSA set values.
  • Would this already be applicable for a fast solution this year?

Fast solution Set-Actual comparison

• As a first step a solution considering transfer lines only could be developed.
• Further proceedings depends on how fast controls can provide a set-actual comparison on FESA level.
  • Ralph Bär stated in a later talk that this functionality should be ready for the beam-time 2019/2020. He recommends to avoid chain execution prevention right from the start but to log and analyze comparison results as a first step.

More required device-related functions

• Extended device type-specific device status
• Setting special setting e.g. gain for cups
• In the old system tasks have been performed using so called Nodal programs

Other discussed topics

Working with historical settings

• Compare settings
• Rollback to previous setting
• Mark current settings as good
• Should be discussed as separate topic

-- ChristianHillbricht - 17 Jan 2019