| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Alarm severity in PVA |
| From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Kasemir, Kay" <kasemirk at ornl.gov>, "Cobb, Tom (DLSLtd,RAL,LSCI)" <tom.cobb at diamond.ac.uk> |
| Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Mon, 14 Feb 2022 12:02:31 -0800 |
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.