Connection flag and alarms with pvmanager

[gcarcassi]

The transition from utility.pv to pvmanager increases the number of possible states of disconnects and alarms. Here we want to define how these are notified to the user, bearing in mind the new use cases.

Pvmanager returns the following:

• connection flag - always present for reader. true/false
• write connection flag - always present for writers. true/false
• alarm severity - only present if value is available and only for a subset of vtypes. none/minor/major/invalid/undefined

The following cases are all valid:

• disconnected, no value/alarm. The channel is waiting for connection. An expression is partially connected to some channels, but needs the other to produce a result
• disconnected, value/alarm present. An expression is partially connected to some channels, but can produce a value (e.g. an array created from multiple pvs)
• connected, no value/alarm. The channel is connected, but the value is not of requested type. Values are taken from the network, but the formula takes time to compute. The connection notification arrived well before the actual value.
• connected, value/alarm present. By far the most normal case
  The 2nd and 3rd possibilities are new, and some application (e.g. BOY) do not handle those cases well.

Proposal:

• If value is present, user feedback (e.g. border, ...) should be based on the value only. In case of a formula, the functions can then decide what is the logic to be used much better than anything else. Therefore, disconnected+value, should look at the value for the alarm.
• If value is not present, user feedback should be based on the connection flag. Connected+no value should be the same as an invalid alarm. Disconnected+no value should be treated as disconnected

This logic will be embedded in a utility function:
Alarm VType.toAlarm(PVReader<?> reader)
The return will always be non-null. Based on severity, the correct display is:

• none - nothing to display ((dis)connected + value with no alarm or value that does not have an alarm)
• minor - minor alarm ((dis)connected + value with minor alarm)
• major - major alarm ((dis)connected + value with major alarm)
• invalid - no valid value (connected+no value or connected+invalid value)
• undefined - display disconnected (disconnected+no value, (dis)connnection+value with undefined alarm)

[kasemir]

I like connected+no value -> invalid.
That's a case easily overlooked without a VType.toAlarm() helper, if you only look at the value.

I am uncertain about all the disconnected + value cases. Why not make them all -> undefined?
If you're disconnected, how can you have a value?
It can only be an old, bad value.
Mapping disconnected + value-with-no-alarm -> none could be very misleading: Looks fine, but in reality you have no idea what's going on.

[gcarcassi]

I am also uncertain about the disconnected + value.

Above says you can have disconnect + value in the following cases:

• =arrayOf(‘pv1’, ‘pv2’) Say pv1 connects and pv2 does not, connected=false. But you still get an array, say [1.0, NaN], with an Alarm that could be, depending on the definition of arrayOf.
• pv1 Was connected, now it’s disconnected. The value is the old value, but will have undefined as alarm. The datasource takes care of that

The point is: if you have the value with alarm, the value tells you more than the connection flag. If the connection takes precedence, then the formula can’t tell you what’s really going on. So, for example, suppose I have a function:

countConnected(‘pv1’, ‘pv2’, ‘pv3’,…)

that counts how many values you are getting from those pvs. You should get an integer with no alarm, because, even if the pvs are disconnected, the value you generated is perfectly valid. To me, the function takes precedence. If the input has an alarm, it’s up to the function to propagate the alarm.

If you have a value without alarm, you are probably right: the connection should take precedence. Because the value you have may be a value before the disconnect.

Gabriele

From: kasemir [mailto:notifications@github.com]
Sent: Thursday, June 13, 2013 11:57 AM
To: ControlSystemStudio/cs-studio
Cc: Gabriele Carcassi
Subject: Re: [cs-studio] Connection flag and alarms with pvmanager (#57)

I like connected+no value -> invalid.
That's a case easily overlooked without a VType.toAlarm() helper, if you only look at the value.

I am uncertain about all the disconnected + value cases. Why not make them all -> undefined?
If you're disconnected, how can you have a value?
It can only be an old, bad value.
Mapping disconnected + value-with-no-alarm -> none could be very misleading: Looks fine, but in reality you have no idea what's going on.

—
Reply to this email directly or view it on GitHub #57 (comment) . https://github.com/notifications/beacon/Be1v7UgUCUsYVtiO8QotJAZWan64cy9vTM6UVfiZuxkTuY-2l699Q061W7KkBegG.gif

[ralphlange]

How will this handle read and/or write permissions, or the lack of?

Being connected with no permission is different from not being connected.

[ralphlange]

After talking this through with Gabriele, I agree with his proposal.

Even for a value that has no alarm, the connection flag makes sense and three meaningful cases can be distinguished:

• none - value
• invalid - connected and no value (e.g. no read permission, incompatible data type)
• undefined - disconnected and no value (e.g. misspelled channel name in the set of inputs)

[gcarcassi]

Rewriting this, because the mail reply was awful!

I am also uncertain about the disconnected + value.

Above says you can have disconnect + value in the following cases:

• =arrayOf(‘pv1’, ‘pv2’) Say pv1 connects and pv2 does not, connected=false. But you still get an array, say [1.0, NaN], with an Alarm that could be, depending on the definition of arrayOf.
• pv1 Was connected, now it’s disconnected. The value is the old value, but will have undefined as alarm. The datasource takes care of that
  The point is: if you have the value with alarm, the value tells you more than the connection flag. If the connection takes precedence, then the formula can’t tell you what’s really going on. So, for example, suppose I have a function:
  countConnected(‘pv1’, ‘pv2’, ‘pv3’,…)
  that counts how many values you are getting from those pvs. You should get an integer with no alarm, because, even if the pvs are disconnected, the value you generated is perfectly valid. To me, the function takes precedence. If the input has an alarm, it’s up to the function to propagate the alarm.

If you have a value without alarm, you are probably right: the connection should take precedence. Because the value you have may be a value before the disconnect.

---

After discussing with Ralph, I am back of the opinion that if a value object has no alarm information, we should treat is as there is no alarm. If you wanted the alarm, you would have created the object to extend the Alarm interface. So, if you want that, you should go back and fix the object, since there are so many cases that could not be distinguished properly.

[xihui]

For the case of connected with no value, instead of returning a null value, could it return a VType value that has null value inside and non-null alarm severity? For example, VDouble.getValue() may return null and VDouble.getAlarmSeverity() returns invalid. This way, it's easier for clients to process the value, for example, they don't need to pass pvReader around and they always only need to deal with the value.

[gcarcassi]

Xihui: that does not work. Not all VType have a getValue(). VTable does not even have an Alarm. So it wouldn't help there. Plus: in general I don't know which type I am supposed to return, even if I am connected. The channel may be connected, but the type can be a function of the payload. If the problem is that the payload is not coming in, or not being processed correctly, then nothing can be made up in a consistent way.

[gcarcassi]

I have added a ValueUtil.alarmOf(Object, connection) with the current strawman behavior
I have not added a alarmOf(PVReader) because, quite frankly, it's not clear to me where to put it. I can't put it in org.epics.vtype because of the dependency on pvmanager. And I don't have a utility class in org.epics.pvmanager.vtype, so I'd have to create one just for this, and I am concerned that would just be more confusing (yet another thing to discover/look at). So, not quite sure what to do.

[xihui]

Is that possible to add a method to PVReader, such as PVReader.getAlarm()?

From: Gabriele Carcassi [mailto:notifications@github.com]
Sent: Monday, June 24, 2013 9:40 AM
To: ControlSystemStudio/cs-studio
Cc: Chen, Xihui
Subject: Re: [cs-studio] Connection flag and alarms with pvmanager (#57)

I have added a ValueUtil.alarmOf(Object, connection) with the current strawman behavior
I have not added a alarmOf(PVReader) because, quite frankly, it's not clear to me where to put it. I can't put it in org.epics.vtype because of the dependency on pvmanager. And I don't have a utility class in org.epics.pvmanager.vtype, so I'd have to create one just for this, and I am concerned that would just be more confusing (yet another thing to discover/look at). So, not quite sure what to do.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-19907160.

[berryma4]

Thank you Gabriele for adding this!

I think "ValueUtil.alarmOf(Object, connection) " is the way to go ... why the connection arg though?

[gcarcassi]

Eric: The connection arg is needed to distinguish the cases disconnected/no value (show DISCONNECTED) and connected/no value (show INVALID)
Xihui: look at the plugin dependencies and you'll see why that's not possible

[berryma4]

Ah, yes ... thank you!

On Mon, Jun 24, 2013 at 2:02 PM, Gabriele Carcassi <notifications@github.com

wrote:

Eric: The connection arg is needed to distinguish the cases
disconnected/no value (show DISCONNECTED) and connected/no value (show
INVALID)
Xihui: look at the plugin dependencies and you'll see why that's not
possible

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-19924287
.

[gcarcassi]

The behavior is now implemented in probe. I have been using it for the last few days and feels reasonable to me.