2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Definition (or not) of alarm limits |
From: | Timo Korhonen via Core-talk <core-talk at aps.anl.gov> |
To: | EPICS Core Talk <core-talk at aps.anl.gov> |
Date: | Tue, 8 Mar 2022 08:39:04 +0000 |
Hi all, We noticed recently that if for instance the lower alarm limits are not explicitly defined in the EPICS database, CS-Studio reports all limits to be NaN. See here
https://github.com/ControlSystemStudio/cs-studio/issues/2716 for a description and a following discussion. Kay pointed out that even when the limits are explicitly defined as 0, the IOC reports them as NaN. Now this starts to smell like a bug. But before I submit a bug report, I wanted to ask if there is a reason behind this
behavior? Maybe it is a feature and not a bug? There is another interesting case, described by Kay in the above issue report, when only one HIGH and not HIHI is defined. How should this case be interpreted? The “Process Database Concepts” documentation (
https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-conditions-configured-in-the-database ) indicates that the alarm limits express a range, however not very explicitly. But this is not consistent with this case. Any thoughts? Timo |