GUI: Convert table of motors perspective to OPI.

[aaron-long]

The table of motors perspective is quite slow and relies of Java development to modify (or extend). We should convert this into an OPI, and dynamically load motors based on which ones are present. This can be done using a similar technique to how the reflectometery server loads parameters. We could gain a performance increase, ease the ability to modify and change to support requests like [#4035].

In the attached image I created a mock OPI table that would load the three galil's and automatically grid their layout using a CSS widget.

Acceptance Criteria

• The table of motors perspective loads an OPI base motor table
• The table of motors OPI has equal or improved performance compared to the existing implementation
• The table of motors OPI dynamically loads motors based on IOC's etc
• When double-clicking on a motor, the motor details panel opens alongside (not replacing) the table of motors (this is a requirement for e.g. polaris), so that I can see the details of one motor while also keeping an eye on all of my other motors.
• The colour preferences still apply

[Tom-Willemsen]

Further acceptance criteria:
- [ ] When double-clicking on a motor, the motor details panel opens alongside (not replacing) the table of motors (this is a requirement for e.g. polaris), so that I can see the details of one motor while also keeping an eye on all of my other motors.
- [ ] The colour preferences still apply

copied to above

[kjwoodsISIS]

Can we document (in this ticket) exactly what controls, fields, etc. should appear on each tile of the ToM.

[John-Holt-Tessella]

This ticket would just reproduce the current table of motors at the time that it is implemented. The ticket you are thinking about which increases the value is shown on #4035.

[aaron-long]

John, Dom and I had a discussion about this ticket following work completed for #5063 which is the Java approach to implementing #4035 (Add more details to the table of motors).

In general we would prefer to work towards implementing OPI's and write less (Java) code ourselves. If we continue to develop this Java implementation then we actively make this ticket harder for ourselves. Our conversation was focused around stopping and thinking about what direction we would like to go in before committing too heavily to one option. We spent time to think about the pro's and con's of a given implementation.

Previously one of this big blockers for the OPI implementation was the requirement that detailed motor views (from clicking a single motor) should be placed into tabs beside the table of motors. This is the current behaviour in the GUI. But the question is: is that actually a requirement? We can feasibly open individual motors in a linking container trivially, or populate fixed tabs (much like the eurotherm). We want to ensure that given a solution the ability to compare motor details is still easy.

Another point was for colour options (colour blind settings) to pass from the GUI to the OPI. We do write to internal PV's so this could be achieved (see: DAE UI for the spectraplot loc://_LOCAL:SPEC:%s%s etc).

I will create a mock of the table of motors without tabs and inquire with instrument scientists as to if tabs are a hard requirement. I will lay out some of the pro's/con's discussed in this post. Given a suitable response we will either think about how to overcome this limitation (if the general response is tabs are required) or if we should continue to implement the Java version.

[aaron-long]

Mock of non-tabbed focused motor details

[aaron-long]

Feedback

POLARIS:

1. Seeing multiple motor views simultaneously is a nice feature when trying to home slits. However it's not super critical as they only do this a few times per cycle. If the screen is quick enough that they can set multiple homes off at the same time it will be fine.

ALF:

1. Occasionally uses the table of motors to zero offsets drift that require resetting. Typically only looking at one motor at a time.

Notes

1. Maybe making the home button intractable would be useful for a future ticket? I would be worried about users accidentally clicking this though. If it's possible to provide a pop-up dialog to say "Would you like to home this axis".

[KathrynBaker]

We might be able to provide POLARIS with similar functionality by coming up with a “group home” option – simplest would be a home all, but providing a way to home only selected axes could be a longer term solution.

[John-Holt-Tessella]

We did write a script for IMAT which calls home on all motors in a list. We could give them a similar script. Although this did expose a problem where sometimes motor homes don't finish.

[aaron-long]

[aaron-long]

Motors perspective

• Changed motors perspective in the GUI to point to an new motors perspective OPI (motors_perspective.opi)

The motors perspective has three main components: Table of motors (table_of_motors<_advanced>.opi), motor details (linking container within the motors perspective) and, perspective controls (motor_perspective_controls.opi):

The perspective controls allows for the user to select either a standard motor details, or advance motor details for the currently selected motor or for the minimal motor object in the table of motors. This is achieved by have local macros used as triggers for the objects script that hold the currently selected motor and enabled/disabled state of standard vs advanced.

When the table of motors is resized based on if a standard or advanced table of motors OPI the controls and details are shifted by a constant (defined within the objects script). In testing I found that while I wanted to simply calculate and offset + width of the new table size (such that the tables can be altered without changing these constants), the width value returned by getPropertyValue for the OPI that had just been loaded would be the old value.

Compared to the old table we no longer have the column/row headings (1, 8) which have gained us some space. It's debatable if it's required but after discussion we want to try to release it without the headings.

Table of motors

The standard and advanced table of motors contain a grid layout (that auto-formats the widgets). Each widget is a linking container that has an associated macro (for the motor) and the standard or advanced minimal motor OPI.

Table views have:

• A PV_ROOT macro of $(P)MOT:MTR
• A MOT macro (per widget) of the motor address (i.e., 0101)

Minimal motor view

• Created new minimal motor standard and advanced views (single_motor_<standard/advanced>_view.opi)

The minimal motor view for both standard and advanced has been redesigned with new status icons. The standard icons have been given descriptive tool tips and highlight. The standard view mimics the existing behaviour. The advanced view provides new functionality; currently the advanced view still requires tweaks to formatting and content. I have placed alternative advanced view layouts in the minimal_motor_adv_templates.opi.

Status Icons

• Created a range of new status icons

Status icons have been created and are saved in ../Resources/icons. This includes the .xfc GNU standard image templates that can have their colours/layers altered with ease.

Currently the status icons are linked to their associated PV. These are linked via macros that are defined in the single_motor_<standard/advanced>_view.opi files.

• After some initial feedback it has been requested that these icons have tool tips that update ("Encoder present", "No Encoder")

mymotor.opi / details.opi

These OPI's have been subtly changed. The buttons to switch between have been removed. The button for MSTA_Details has also been changed to be a pop-out as it's only used rarely for debugging.

Known bugs

• Right clicking on manager mode protected button allows for the execution of the widgets action

[Tom-Willemsen]

Current performance on SCIDEMO is about 3x slower than the java ToM when opening the perspective (having already opened one OPI, as the very first OPI to open is always slow).

Java-based ToM: about 5s between clicking the perspective icon and a full render of the ToM:

OPI-based ToM: about 15s between clicking the perspective icon and a full render of the ToM:

It looks like we will need to put some thought into the performance of this solution.

[Tom-Willemsen]

@DominicOram @John-Holt-Tessella @FreddieAkeroyd @ThomasLohnert and I discussed the comment above, and decided that:

• We will push on with this OPI-based solution anyway
• We will write a ticket to optimize it ( Table of motors: optimize startup performance of OPI-based ToM #5320 )
• We will try to load the ToM in some way as the GUI starts (maybe by starting on the motors perspective) to attempt to hide the delays as much as possible. Unfortunately OPIs always run on the GUI thread so we won't be able to do this initialization "in the background" - it will always block the GUI while it runs.

Longer term we may look at implementing the individual motor widgets in CS-Studio (in Java code) to try and regain some of the performance penalty of using OPIs.

[John-Holt-Tessella]

Things left:

Accessibility back ground colour and connecting local pv :
Font size in advanced view:
Disconnect:
Buttons for selecting advanced & more details move so they don't get in the way (possibly just have the two for the non-active modes):
Axis highlighting when SP != RBV + tolernce: tolerance should take into account retry deadband vs motor resolution vs encoder resolution
Tabs for other motors 9->16 and 17->24:
display both high and low soft limits, offset, val, sp and error on the "advanced" view.

tickets

#4633 this ticket
#5065 advanced view
#5064 normal view
#5063 switch between normal and advanced view
#4035 general overview ticket

#5320 Performance doing after this is complete

[John-Holt-Tessella]

Performance in the end was too bad to carry on. We think this was caused by the number of PVs which must be connected and rendered on this view. Maybe it will be better to diaply builder but currently not good enough in BOY.