Indication of 'disconnected' state. Is the following a bug?

[claudio-rosati]

Hello all,

I'm trying to build a motor control to be embedded in other OPI, functionally similar to this one, but with a better and modern UI.

I'm using BOY to do it (and it will serve a testbed for a Display Builder widget I was requested to create).

As you can see, there are a lot of small widgets packed into this controller, all referring do different fields of the same motor PV.

All this widgets' border and background are set NOT being sensitive to alarm, because I don't want a "panic UI" where everything get colored because of an alarm. There will be just a LED for this purpose placed near the controller's title bar.

The problem arises when there is no connection with the PV, because nevertheless I explicitly set the borders and the backgrounds NOT being alarm sensitive, everything is magenta-colored with the "Disconnected" text inside (in Display Builder everything has the magenta-colored dashed border around).

I think this is an error, preventing to build smart, "no panic UI". Is there a way to prevent it? Can we add a way (a specific property maybe) to prevent it?

Can someone pointing me in the right plug-in's code in order to see if/how this can be done?

Thank you in advance,
Claudio

[claudio-rosati]

Moreover, a good thing will be having options in the Linking Container (Embedded Display) to "capture" the alarms from the linked content and display them compatibly with its own alarm sensitivity settings.

This way I could have an alarm border in the container instead of/together with the content, if enabled.

[kasemir]

The 'disconnected' must be indicated.
It's a severe error, and even if a widget is otherwise not configured to be alarm-sensitive, we must indicate that the current value is not known, whatever the user might think they see is invalid.

As for summarizing other alarms beyond the disconnected indication, I don't see a general use case.
You can't generally summarize all the embedded widget's alarm severities.
This needs to be done by the IOC, which knows what the individual signals mean.
You could then create a sub-display which indicates the status summary via a text and LED for example in the upper left corner. You could also have a rectangle with rule to change the color around the widgets, still inside the sub-display.

[claudio-rosati]

That is what I don't like: not having the possibility to get rid of the 'disconnected' border/message.

[claudio-rosati]

I try to better explain my point: When my motor is off (disconnected) I don't want all these magenta things, but only my led close to the title (GREEN on the left picture) becoming magenta, otherwise despite all the efforts to create a good and professional UI, it will always appear bad, creating a sense of panic.

[kasemir]

We must not hide the disconnected state from users.
Disconnected is really bad. Every user must be able to see right away that the display doesn't know what to show. Disabling the indicator and misleading a user that the value shown on the display is valid can have much more severe consequences than a user not liking the color of the border.

Do you have a use case where a disconnected display is actually expected, part of normal operation?
On beamlines, there may be some movable device that's simply not present at the beam line right now.
So the display for it is all disconnected.
Normally, users would then close that display, since the device handled by the display file is not in use right now.
If you do show some summary of that device on a top-level screen, there are a few options.
Best would be to handle the summary in some beamline status IOC.
The PVs in there will then say "Not present", without any alarm.
Or add a rule to the display to make the embedded widget invisible.

[claudio-rosati]

I agree with you partially: I would like leave to the designer how to show a condition to the user.

Anyway, for my Motor Controller everything will be solved with a widget in Display Builder: at least there will be a disconnected border only around the whole controller/widget, that is what I'm unable to realize with BOY and Display Builder creating an embedded display.

[kasemir]

If a designated 'motor' widget asserts that a disconnected state is indicated: excellent.
That's one widget, with one PV (plus related PVs like $(motor).DMOV, $(MOTOR).JOG etc., all related to the same $(MOTOR) motor record. .. except when it's a newer type of motor driver based on assign that has additional PVs beyond the central motor record, but maybe that can't be supported with a generic motor widget? .. different topic.

For the embedded example from your screenshot, I think the prevalent use case is that the display is attached to an existing motor, where everything is fine.
What about the 'panic' case, why would it be used with a missing motor?
If that's on purpose, a rule can make the embedded widget invisible -> Good, user won't panic.
If the motor is supposed to be online, several purple borders are OK. This is a problem, a certain amount of panic is justified, and seeing which widgets are disconnected, being able to see the PV that's disconnected is helpful in efficiently resolving the issue. I don't think it's enough motivation to complicate the code by passing all alarms up via parent widgets to the display model. Besides, what to do with that information at the display model level? If it's an embedded widget, update the widget's border, but what if that has been disabled as well? If the display is not embedded, have a border around the window? Finally, once we get some higher level border to change, how would we determine the PV that's actually disconnected? Percolate not only the alarm severity but also the PV names up to the display model?
In comparison, I think the simple approach of indicating disconnected state right away on each widget is more efficient both for the implementation and in practical use.
For what it's worth, the color is already customizable, it's the 'DISCONNECTED' named color. For EDM, it was white, and then we switched to purple because it stands out more. If you prefer to tone it back down, that's an easy site-specific adjustment.

[claudio-rosati]

A specific motor widget clearly will simplify things because itself will be a single object, and there will be a single standard disconnected border around it.

The widget I was asked to implement will deal with a single PV. Before implementing it (I will start next week implementing the simpler widgets I've already planned), we could have a chat about it, maybe after looking at my current BOY implementation (that will be hosted here today).

About the disconnected border:

• I agree that the final user must know about the disconnected PVs;
• I agree that there must be a consistent way to represent this information (color code, border, ...);
• I also think that the OPI designer (the one that will use BOY/DB editor) should be free to disable that information depending on some design constraints/choices (for example, grouped widgets referring to the same PV).

So my proposal is the following:

• having an advanced Disconnected Representation property for every PV-based widget, allowing to choose from the following alternatives
  • Border and Caption, default value, as it is working now,
  • Border Only, drawing only the border without the "Disconnected" bar and caption,
  • Disabled Widget, just disabling the widget,
  • None, doing nothing.
• advanced properties should be made available only if the corresponding setting is checked in the application's preferences.

Clearly enabling this property will give more responsibility to the OPI designer and to the one that must test the OPI before putting it in production. Do you think is it still too much or risky?

I have also the following question partially related to the problem: how is it possible to know in a rule/script that a PV is disconnected? And a macro not defined?

Thank you,
Claudio

[kasemir]

How should "do nothing" work?
For a text update, leave the last displayed value there, so the display is wrong?
I can't support that. The widget needs to somehow indicate that there's no value.

As for detecting disconnected state in a script: Good point!
Scripts will by default only execute once all PVs are connected.
By the time the script is actually running, one or more input PVs may have disconnected, so the 'read' can check for a null value.
I just added that to the display builder: Scripts are only invoked when all PVs are connected.

BOY has the option to "Execute anyway even if some PVs are disconnected".
With that one could trigger the script by "sim://noise" and the PV to check as a secondary PV, use the the "Execute anyway.." option, and see if the other PV has a value or not.

For the display builder, I'll add an option to "Execute on value or disconnect", so one can trigger the script with just that PV.

[claudio-rosati]

"do nothing" should exactly doing nothing. Out motors groups want to see the last value.
Clearly is up to the OPI designer to choose which king of visual notification to implement.
The real problem is that if rules/scripts will not run if disconnected or they cannot know about this status, the OPI designer can do nothing, and only in this case I agree with you that it's not good.

[kasemir]

Display builder now has an option on scripts to execute script even if PVs are disconnected.
It's similar to the "checkConnect" option in BOY scripts:

If a script is triggered by some PV, it will still execute even if other PVs are disconnected.
So one could use it with pvs[0] = sim://noise to trigger, and then check pvs[1] = whatever for the connection state.

The display builder option additionally triggers when PV is disconnected.
So just pvs[0] = whatever as trigger PV will execute the script when that PV has a value and when that PV disconnects.

The script example shows how that's used to hide a widget when the PV is disconnected.

Overall, this means by default widgets will indicate missing PVs, but if a very special display wants to hide that, it can.

kasemir/org.csstudio.display.builder@ea1336f