2018 12 04 RIKENFE, MUONFE, EMMA demo

The Muons seem to have only a few main tasks that repeatedly need to be performed but by a high volume of different users. There were many concerns around giving the current system to inexperienced users, both in terms of user-friendliness and robustness/error prevention.

EMMA was absent.

More specific feedback, vaguely categorized:

Functionality

• A script generator is far more important than a script server. You should be able to feed scripts from the former directly into the latter.
• They also asked for an OPI backed by a script - i.e. you enter parameters, hit send, which then populates a script underneath. Like a halfway script generator. This may require further clarification.
• Would like a non-linear Synoptic diagram to reflect the Muon beamlines.
• Would like to replace the Motor perspective with a Magnet perspective for their instruments.
• Some other requests, see 1195, 3274, 3489, 3848

Usability

• They presented us with the following use case: Confronted with the GUI on RIKENFE, an inexperienced user ("I have 30 seconds to explain the UI to them") is tasked with turning power supply RB-4 off. Where would he look? It is pretty overwhelming - we need to think about how to guide users better. Maybe it is worth thinking about the language we use and makes it more high level / descriptive, e.g. IOC -> Device Drivers?.
• They would like to have more control over which perspectives are visible to get rid of clutter.
• Interaction is mostly turning magnets RB3/4 on and off. They would like buttons for this in the footer bar (like the "stop all motors". Can we make the bar more configurable?
• They want simplified user commands with simple syntax (no prefix or brackets) for common procedures. We said:
  • You can define your own common procedures (they accepted this)
  • We can look into getting rid of the inst prefix for Muons
  • Getting rid of brackets on method calls might prove difficult
• Asking for a view of both log plotter and scripting console next to each other. This should be covered once we have custom save-able E4 layouts.
• Asking for the ability to save settings for a log plot to a configuration.
• Asked for the y-axes on a log plot of more than 1 block to be merged.

Access Control

• They need a core of fixed "safe" configs that users cannot meddle with. This is of vital importance.
• They were concerned over users writing to arbitrary PVs which could lead to odd behaviours in IOCs. We said this may be difficult to prevent completely, but we try to hide PVs from users and they should only really have to interact with blocks, which they seemed satisfied with.

System Status Feedback

• Alarm view seems to not be working on RIKENFE.
• They generally think the Alarm view is useful but would like a clearer presentation of current alarms, with less drilling down.
• They would like to see alarms on components in the synoptic view.
• They would like to improve the propagation of alarm states in their IOCs. As an example, they referred to their XFD1 power supply. The device was disconnected at the time, but the blocks just showed nonsensical values with the only indication that something is wrong being an INVALID alarm on the power status block. They would like it to be clearer when a device is disconnected while the IOC is running, and the values to show NaN.
• They were asking if it would be possible to show alarms from their PLCs in IBEX. Apparently, there is a web interface for these alarms, we don't know how easy/hard it is to access this interface.