| 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: | "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov> |
| To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>, "Cobb, Tom (DLSLtd,RAL,LSCI)" <tom.cobb at diamond.ac.uk> |
| Date: | Mon, 14 Feb 2022 13:29:10 +0000 |
|
> 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, ...). 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.
|