GUI: Display more information on table of motors

[ThomasLohnert]

As a reflectometry scientist, I would like the motor table to display much more information about each motor to provide a kind of glanceable overview of the state of all motors similar to SECI, instead of having to drill down on every individual one to see the details.

Specifically:

• Display an indicator that shows the motor automatically de-energises
• Display an indicator that shows the motor is using an encoder
• Setpoint and read back should be display at the motor precision
• Display the motor limits
• Display the offset
• Display when there is an error between SP & RBV

Consider whether there should be a basic and advanced version of the table of motors (where the advanced version has the above features)

Acceptance Criteria

1. As above now displayed
2. All items originally displayed are shown
3. Colour preferences still change colours to be more easily distinguished

[John-Holt-Tessella]

Maybe this should be a real table like this? Might need to do this to save space

[ChrisM-S]

This looks pretty informative to me, but I'm curious, does SECI have something like this for reflectometers? Am I right in assuming that the icons can be pressed to home/move to limits? Also would multiple motors moving be updating in real time?

[ThomasLohnert]

Yes SECI has all of the above in their table of motors as far as I know, and yes it updates all moving motors in real-time (as does the IBEX table of motors).

We can ask the scientists what they think of the table view but my hunch is they will not be too happy with it as it doesn't provide the same information density (something they have repeatedly said is a major requirement) as the grid view in SECI. I also imagine there would already be some degree of resistance because the format would be quite different to what they are used to.

[kjwoodsISIS]

The table-of-motors in IBEX was one of the early features that we created, so I am not surprised it is not as functional as the SECI ToM. We should sit down and compare the IBEX & SECI tables-of-motors side-by-side, identify the gaps and make plans to fill them.

[John-Holt-Tessella]

Yes we should sit down and discuss.

[kjwoodsISIS]

Ask scientists if having this information on a separate screen would be acceptable.

[aaron-long]

I think as part of this ticket we should design a table of motors .opi that can eventually supersede the motor table perspective in the GUI. Here's a working example of a dynamic table I created that will fit (in a grid layout) automatically motors.

We can more easily edit and design the OPI, as well as remove Java code.

I created ticket [#4633] to propose this.

[aaron-long]

Mock layouts for single motor details that preserve (at a minimum) vertical space:

[aaron-long]

[aaron-long]

[aaron-long]

[aaron-long]

Icons/glyph for status information

I had spent some time thinking of how to compactly show the information in the requirements without increasing the vertical (and horizontal space). I created some multi-info glyphs and experimented with the addition of these to the single motor view. Two designs where seem to satisfy our wants are an in-line glyph or a side stripe.

This would function in the same way as the MinimalMotionIndicator class with boolean on/off depending on the property (i.e., is the axis homed). I feel that icons are preferential to letters but examples are given for both. Colours are for illustration only.

Designs for Table of Motors

@ThomasLohnert and I spent time to think about how to add the additional information to a single motor details panel. Some specific requirements we felt were essential:

• do not increase vertical space; ideally each motor table should be visible without a need for a scroll bar
• Do not decrease font size
• There should be a focus on the VAL
• If a limit is triggered then it should be highlighted and the limit values should be included As a result of these we felt that sticking to 4 rows was needed.

SECI had a lot of information but aligned with text wrapping and a tiny font. Ideally we would like to convey similar information density but in a more readable format:

@Tom-Willemsen & @John-Holt-Tessella Have both noted they think a simple and advance view should be available too, as most users (beyond reflectometery) will not use this info and it might be overwhelming.

[KathrynBaker]

I’m not sure I’m making sense at a glance of this information where the icons are going and what they represent – can you provide an annotated image with what is where, what it means and how it changes between states? E.g. at home position, high limit made, not at home position, etc. At the very least a version with annotations that tell me which is the high limit, which is the low limit, which indicates you are at home or not.

I’m lacking just a little bit of information for the detail in this – I know it’s a mock, but without that detail whilst I can agree it is clean I can’t tell if it is clear.

[aaron-long]

@KathrynBaker The icons would follow the same binary behaviour of the current ones:

The information is the content that is listed in the requirements in the initial ticket.

[ChrisM-S]

Good tool tipping might allow removal of some space taking things like "Axis Name" (i.e. show just the name "MOT" with the tool tip showing the field name). I would still keep sp: and off: though, just a thought.

Tool tips could also document the fields icons better for more context based help.

[KathrynBaker]

OK so lit/unlit is on off – but I’m not sure I can follow from the images which are limits, which are homes. Where the HI and LO numbers are a different colour what is that representing.

There are 4 boxes which seem to mean home and other items, but I’m not sure about that. Two arrows which I’m guessing are direction of travel based on highlighting when the background is green or red – but could they be limits? The text boxes with HI/LO values on them are different colours – which may be for illustration purposes, but what are they illustrating? I still can’t tell if this is clear enough to be a solution – as I can’t actually tell what is going on in the arrayed motor images, it is too ambiguous for me at the moment, and an annotated copy telling me what each of those squares is meant to be at least tells me which information is where. I can’t match that list to the information being displayed.

[aaron-long]

The request for requirements and feedback on the table of motors design has been sent to instrument scientists. CK has kindly agreed to collect this information and we will have a list in a weeks time.

After testing designs for the existing motor single view, I think we would need to consider reducing the font size by a point or two for new values to maintain horizontal spacing.

@KathrynBaker The orange highlighting on the limits label & value simply represents that a limit is triggered (exactly the same as the orange boarder on existing simple/detailed motor OPI). The highlighting on either Lo, HI or both is just the triggered status on each of these.

The coloured squares would represent the status information for values that have binary values, i.e., is an encoder being used. The position, colour and icon are only examples are will not be defined exactly until we have feedback on requirements. The second round of design will define these better and a more comprehensive illustration (with labels etc.) will be produced.

[aaron-long]

Feedback provided by instrument scientists on a proposal for the new advanced table of motors design:

1. The main motors for the Engin-X positioning stage are not treated as IBEX motors. They have a view in Synoptic and EPICS PVs, but are not mentioned in the IBEX table of motors. I forget the reason, but it may be related to the use of our hand-held jog box. If the handling of motors is being improved, it may well be worth looking at including the Engin-X positioning system in the IBEX motor table, to benefit from future development here and mitigate the risks of using a non-standard solution. I also find it hard to believe that Engin-X is completely unique in its requirements – things like our jog box may not be essential for other beamlines, but there must be some situations where it’s useful.

2. I don’t use the Motor view very often at all, thus the clarity of it is actually important. I have to say I quite like this new view having the limits displayed and presumably illuminating if in error… But I’ve no idea what the ‘status lights’ are about!

3. I’ve discussed this with James and we think this looks basically fine – we would quite like to see several motors at once sometimes. I don’t think we have a preference between the two icons – perhaps because we didn’t fully appreciate the difference – but either would be fine. Minor comments we had were:

   • How active would this screen be? Would you always be at risk of adjusting parameters with a single mouse click or scroll. Or is it just a viewing system?
   • Could we click these to get to the OPI’s? That would be very handy.
   • We didn’t have any particular opinions on colour coding as long as it is documented.

4. I’m happy with the proposed changes to the motor table display. I don’t have a preference for one or the other of the two proposed options.

   • I like the use of colours.
   • It’ll be good to keep the option to switch between simple and advanced view, as suggested by Aaron.
   • Having low and high limits accessible on the top level will make some alignments tasks easier for us the users on IMAT. For this we would need the “advanced view” for a few of the axes, not for most axes. So I wonder whether we will be able to customize the motor table such that we can have some motors in simple view and others in advanced view.

5. For information, the reason we have not converted the Engin-X system is related to the handheld jog box, and more importantly it’s interaction with safety requirements. Making changes to the system will likely result in a close inspection of the whole system, and will require significant re-testing at the very least. When Engin-X was converted to IBEX there was no appropriate resource available to undertake that testing – which at the very least will require time from Experiment Controls and Electronics Operations. There is very limited support available for motion related safety at this time, and this system was a compromise that we can make an argument to maintain, but not to develop/alter, the additional slits behaviour is another example of our not altering the system, it is being handled separately. Those of us who have the maintenance responsibility for the system are actually keen to see it migrated to Beckhoff with a modern safety system, at which point it will be part of the standard IBEX setup. Until then, the non-standard system may cause confusion, but we know that it behaves and conforms to the previously agreed safety case, any alterations will require a significant amount of work for which there is no resource and a re-agreement of that safety case which will likely be time consuming. The jog box is unique to Engin-X, where others have the need to perform those functions so far they either cope without, or we are trying to develop solutions with them, and as yet do not have a solution that we would roll out to others.

[aaron-long]

Split ticket into smaller chunks:

• Switch views: https://github.com/ISISComputingGroup/IBEX/issues/5063
• Extended values and new layout: https://github.com/ISISComputingGroup/IBEX/issues/5064
• Status information: https://github.com/ISISComputingGroup/IBEX/issues/5065

We are also reviewing #4633 as an option.

[John-Holt-Tessella]

Review as part of #5064