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