Re: Alarm severity in PVA

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 2/14/22 05:29, Kasemir, Kay via Tech-talk wrote:
> > How should a UI render invalidAlarm vs undefinedAlarm vs "can't connect to PV"?
> > Is there much of a difference to a user of a UI between those three states?
> Good question. In CS-Studio, the display builder uses a very similar variant of purple for both the invalid and undefined severity, and also a very similar dash-dotted vs. dotted border style. So even color-vision-impaired users can tell a difference if they want to, but it's a small difference because either case basically means: Ignore what you see, it's not valid data.  If it's clearly disconnected, text-type widgets show "<PV Name>" instead of the last value, to make it more obvious that we can't connect to the PV and at the same time indicate what PV that is.
>
> But that still leaves the question of when you'd get invalid vs. undefined.
> Not sure if that's fully defined and consistently implemented in all the PVA servers (QSRV, custom C++/python server, ...).
It's unfortunately no so clear to me how to map between the database/CA alarm
model to the PVA NT* alarm.

The way QSRV does it at the moment:

https://github.com/epics-base/pva2pva/blob/f07d14b12dc892e434b5498afe8782e4f3145711/pdbApp/pvif.cpp#L331-L378

https://github.com/epics-base/pva2pva/blob/f07d14b12dc892e434b5498afe8782e4f3145711/pdbApp/pvif.cpp#L404

I make no warranty for this being correct, or even useful.

> ... CS-Studio for example does this:
> If there is no 'alarm' found in the PVA data, assume that it was simply not provided (custom server...) and the alarm severity is OK.
> If there is an 'alarm' structure, but it fails to contain a 'severity', assume undefinedAlarm, else use the severity as received.