-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSSTUDIO-1920 Add alarm limit info to tool tip #2769
Conversation
…ow", "pv_alarm_high" and "pv_alarm_hihi" to instances of "PVWidget".
I think that's the wrong direction. The PVWidget has a "value", which is a VType, and that comes with time stamp, units, precision, alarm state, maybe alarm limits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Misses the point of VType
The code checks that the incoming data point is an instance of
The idea is to be able to access this information with less overhead than with a script. Using a script to update a tool-tip on incoming data points adds much overhead. |
Still no. Updating tool tips to show limits is an edge case that I've never seen as an operational requirement. Or use something like |
We have examples of widgets where users want alarm limits in the tooltip. So they add a script executed on each monitor update. End result is - to give one single example - an OPI executing 46 scripts per second to compute a tooltip that never changes. My idea of binding alarm limits to runtime properties would eliminate the need for such scripts. |
Still, we can't add any potential VType aspect as a widget property. |
BOY had the idea of an "OPI Probe". That's just a display, but it's accessible from the context menu similar to Right Click -> Probe, receiving the PV name as a macro. With something like that you can create an "Inspection" display that shows value, limits, ... in a configurable way, not with a predefined layout as in Probe, and reach that from the context menu. Maybe add that functionality, a display reachable from the context menu? |
@kasemir What do you think about a more systematic inclusion of all or at least more Executing a script adds computational overhead, and opening a separate window in order to determine the alarm limits adds cognitive overhead for the operator compared to seeing the information in a tool-tip. |
The VType fields depend on the type. We can't add low/high warnings and alarm thresholds, units, precision, enum labels, image encoding, image data type, image encryption, image width/height, .. all as widget properties, and then keep doing that as new vtypes are added. That blows up widget size for everybody, for thousands of existing displays, just because you might have a few screens where you want some of the information to appear in a tool tip. The widget properties would be updated with each value change even if nobody ever opens the tool tip. You'll also end up with displays where somebody put If users really need to look into a PV, then opening Probe or the PV Tree is a solid solution that offers access to all the detail. The tool tip is always a little finicky: Need to place mouse on widget and then take care to not move it. Hard to copy values out or take a screenshot. If you really need the PV name or value etc, you can't conveniently get it from a tool tip. Still, it can be a first check of a PV name and value. Line 92 in e6e7b0f
If the VType includes alarm info, it's added. If the VType includes a timestamp, it's added. If the VType includes display info, it's description (only set for PVA) is added. So you already have a track record of adding stuff to the Lines 112 to 116 in e6e7b0f
--> Why don't you go in there and add the alarm thresholds from the display info? This will show the alarm thresholds for PVs that provide them, it's in the tool tip, the code only runs when a tool tip activates. No overhead at all for the widget size and runtime in general. Nothing an end user needs to configure, so no chance to mess it up. The default tool tip will work just fine. |
Thanks for the pointer to this code, I was not aware of it. Adding the information in |
I have updated the PR so that |
This is MUCH better. Still two comments: To get/check a Display, there's You now require tooltips to be updated to include |
I tried to not change the existing behavior unless the user requested it. However, I agree that adding this information to the default tool-tip would make it overall better. I will update the PR with your suggestions. |
I have updated the PR to use the function There
|
Not sure how |
In other words: Don't add a new |
Sorry, I was confusing the variable names I have updated my previous comment to reflect the correction. |
You lost me. |
Only when Line 124 in e6e7b0f
(Somehow the the alarm status etc is bound in the corresponding macro-variable, but not in the call to I have now update the PR to append the alarm limits to |
I chose to print "Undefined" when a limit is not defined, since I think it is clearer for the user. |
That looks very reasonable. As for "Undefined", not sure what the best wording would be. "Undefined" might suggest that something is not quite right, like the undefined/UDF error of PVs that have not been processed. For limits, it's perfectly normal to only set the high but not the hihi etc. "Undefined" as in not-defined is correct, but maybe "not set", "unspecified", or the like are good alternatives to avoid confusion with the very common EPICS error of "Undefined" on PVs. |
Agree, "Undefined" I fear will cause misunderstandings and confusion. My vote is on "not set". |
I have now changed "Undefined" to "Not set". There is one more issue that I can see:
|
I have now implemented option 1 by increasing the default tool-tip length from 150 to 200. I have also changed the labels in the tool-tip to uppercase (i.e., they are now "HIHI:", "HIGH:", etc. instead of "HiHi:", "High", etc.). I think that this PR is ready to be merged now. |
PVWidget
This pull-request adds runtime properties for the alarm limits of widgets that are instances ofPVWidget
.It adds the following four runtime properties to instances ofPVWidget
:pv_alarm_lolo
pv_alarm_low
pv_alarm_high
pv_alarm_hihi
These variables are assigned the limits received with incoming data from the PV.As a consequence, these values can be accessed in macros, and easily displayed in tooltips.This pull-request adds a substitution of
$(pv_alarm_limits)
with the PV alarm limits if these are defined totooltip.setOnShowing()
.