Linear Meter Widget

[abrahamwolk]

At ESS, we have developed a new widget for Phoebus called the Linear Meter.

It looks like this (the colors of the alarm borders are non-standard because of my local Phoebus configuration; they will appear in the same way as for other widgets according to the configuration of Phoebus):

With a gradient enabled it looks like this:

We would like to know whether there is an interest in that we merge the widget into the Phoebus source tree? It would be added in the same way as the Thumbwheel widget, which allows for easy exclusion from builds if one does not want to include it in a build.

In case someone wants to test the new widget, I have pushed the branch LinearMeter to the Phoebus GitHub repository, on which the Linear Meter has been added.

If there is support for an inclusion into the Phoebus source tree, I will open a pull-request.

[kasemir]

That looks good! It might be a better mapping for 'bar' widgets when auto-converting MEDM or EDM screens.
I do like that it's drawn in the background as an image, not a JFX subtree with one "Line" node per tick mark.
With the conversion from legacy 'bar' widgets in mind, a 'fill' option that for example adds a 'bar' from zero to the value would be nice. The little triangle and black line to indicate the value are hard to see when you step back from the screen.

[abrahamwolk]

@kasemir wrote:

With the conversion from legacy 'bar' widgets in mind, a 'fill' option that for example adds a 'bar' from zero to the value would be nice.

There is already the Progress Bar widget, doesn't that widget implement this functionality? Either way, if the Linear Meter widget is merged into Phoebus it would be easy for anyone to add new functionalities to it.

The little triangle and black line to indicate the value are hard to see when you step back from the screen.

The size of the triangle (the "knob") and the width of the black line (the "needle") can be adjusted via the widget settings "Knob Size" and "Needle Width", respectively.

[shroffk]

I think it would be useful to include the linear widget like we included the thumbwheel (maybe in the future we can merge the modules)

[abrahamwolk]

They are included in the same manner on the branch LinearMeter. An advantage for having them in two separate modules is that it is easier to exclude just one of them, if one wishes to do so. But perhaps there are advantages to sharing a module also.

[georgweiss]

@shroffk, not sure what you actually suggest in terms of code structure. Discussing this with @abrahamwolk I suggested to add the linear meter as a separate maven module, just like thumbwheel. That way the widgets can be excluded in a product pom rather than building them into a product, and then configure visibility.

[kasemir]

For what it's worth, there's also the hidden_widget_types setting for the editor, https://github.com/ControlSystemStudio/phoebus/blob/master/app/display/editor/src/main/resources/display_editor_preferences.properties

With bar, tank, linear meter, meter, .. all serving a similar purpose, displays will look inconsistent if everybody picks a different widget. As a maintainer of cs-studio for you site, you may decide to hide all but one of those variants in the editor. This means users at your site can only create displays with one of those variants. But you can still include the support for the others, such that displays created elsewhere that happen to include those widgets will "work". You can then update them to use the widgets that you prefer, but you're not looking at a blank screen until you do that.
Area detector is an example for something that comes with many displays that you may have created differently to suit your local preferences, but they "work", so you'll simply use them as "engineering screens" and not re-do all of them.

[georgweiss]

OK, point taken.

But to me this calls for a decision of strategic kind: should the code base be structured such that a site specific product would always include all widgets for the sake of reasonably predictable runtime behavior? If yes, then the thumbwheel (and linear meter) widget code should not live in a separate module.

[shroffk]

@shroffk, not sure what you actually suggest in terms of code structure. Discussing this with @abrahamwolk I suggested to add the linear meter as a separate maven module, just like thumbwheel. That way the widgets can be excluded in a product pom rather than building them into a product, and then configure visibility.

I was indeed suggesting including it as a separate module... since we are talking about testing the widget and determining if there is a need for it given the existence of the progress bar.

Once we are satisfied that the widget is stable enough we can include it into the main display module and switch to using the visibility preferences to control its usage.

I think we can put experimental/first iteration widgets in standalone modules until we are sure that we want to take the responsibility of supporting them (in the runtime at the very least) for the foreseeable future .

[georgweiss]

OK, I understand. Personally I prefer the module-based approach and exclusions through site-specific product pom. After all, excluding modules is optional, the consequences of exclusions must be known by the maintainer of the site-specific pom.

In any case, I am fine with the suggested approach.

[abrahamwolk]

In the merge-request I will add the widget as a separate module in the merge-request, and then it can be integrated more directly into the project some time in the future.

The implemented widget diverges from other similar widgets in Phoebus in two ways:

1. There is no internal update throttle in the widget. Instead, the widget relies on the global update throttle for PVs of Phoebus, i.e. the setting org.csstudio.display.builder.runtime/update_throttle which defaults to 4Hz.
2. The widget will display warnings inside of the widget in certain conditions, e.g. if a value is less or greater than the minimum or maximum displayable values, no unit is defined (and displaying the unit is enabled), the PV defines no limits (and "Limits from PV" is enabled), or lag is occuring (the widget cannot update as quickly as values are received). The Lag-warning works as follows: if the widget receives a value, and then it receives another value before it has been able to print the first value it received, then only the second value will be drawn, together with a warning that says "LAG". (A warning log-message is also logged.) It looks like this:

The rationale behind printing the LAG-warning is that there are performance problems with the OPI if lag occurs, and the user should be aware that the performance problems are there (and they should be fixed, perhaps by improving the efficiency of the code, fixing the OPI itself, or some other solution).

Before I create a merge-request, I would like to ask whether point 1. and 2. are OK?

[kasemir]

1 is no problem at all. TextUpdate etc. also just use the general runtime PV throttle

2 might be overthinking the issue. The display is to make a best effort of showing the most recent value. It's understood that some intermediate values might have been dropped. The general runtime PV throttle drops values to lower CPU load. Channel Access drops values without ever telling you. PV Access does have an "overrun" bitset in the subscription update messages (https://github.com/epics-base/pvAccessCPP/wiki/Protocol-Operation-Monitor#response-encoding-server---client), but that's just a flag, you don't know if you missed 1 or 1000 values. Sure, you can add a lag indicator for your widget, but it'll be unaware of many dropped values.

[abrahamwolk]

Sure, you can add a lag indicator for your widget, but it'll be unaware of many dropped values.

The idea is that it may indicate performance problems with the OPI or widget. I think that in a control room, an OPI should be able to display any incoming value without problems: if values have to be dropped because of insufficient performance, that's something I think the operator should be aware of. (I.e., it should not happen.)

[kasemir]

I appreciate your concern, but by the time you display the lag message and the then-current value, the problem is gone.
Instead of "LAG", "Everything's great now!" would be a more appropriate message.
If you want to detect missing updates as they happen, you need to add some heartbeat PV that changes for example every second and then check if you see that. For Channel Access, you can adjust the beacon period so that you see "disconnects" much earlier. At SNS, we tried both and ended up with many misleading warnings whenever there's a temporary network slowdown.

But again, do what you want to do with your widget.

[shroffk]

Thanks again for adding this widget.

Regarding with the "LAG" indicator, while I understand the concern to notify the user that the system is unable to process all incoming events... as Kay pointed out there are multiple points along the pipeline where updates are dropped (most of the times without notification)
We have users that use the same screens in multiple context...the control room desktop which is on the controls n/w, their office computer which accesses via a gateway, then there is VPN and finally the dreaded x11 forwarding across multiple ssh servers. How would the LAG warning behave with the last 2 situations?

[abrahamwolk]

The LAG indicator is not meant to notify the user about dropped packages; I think that this should probably also be done, but it is outside the scope of this widget. The LAG indicator is supposed to indicate that the performance of the computer running the OPI is insufficient to update the widget with each incoming data-point (i.e., incoming to the Linear Meter widget).

For instance: suppose org.csstudio.display.builder.runtime/update_throttle is set so that updates are throttled to 4 Hz and suppose a PV sends values so that the Linear Meter widget after the throttling has occured receives values at approximately 4 Hz. If the computer is not able to render the Linear Meter 4 times a second, but perhaps only 3 or 2 times, then the LAG indicator is shown whenever a value has been skipped.

[abrahamwolk]

My guess would be that if Phoebus is run using X11 forwarding over SSH or VPN, the code that renders the widget is run on the computer running Phoebus, and only the graphical output would be sent over the SSH- or VPN-connection. If this is the case, then the LAG-warning would only be shown if the computer that renders the widget is not fast enough.

But I don't know how X11 forwarding works, so perhaps my guess is wrong, and perhaps the X11 forwarding somehow impacts the rendering of the widget.