Open aaron-long opened 5 years ago
~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
Can we document (in this ticket) exactly what controls, fields, etc. should appear on each tile of the ToM.
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.
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.
Mock of non-tabbed focused motor details
POLARIS:
ALF:
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.
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.
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.
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:
PV_ROOT
macro of $(P)MOT:MTR
MOT
macro (per widget) of the motor address (i.e., 0101
)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 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.
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.
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.
@DominicOram @John-Holt-Tessella @FreddieAkeroyd @ThomasLohnert and I discussed the comment above, and decided that:
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.
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
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.
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