EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Base V4 Database: Alarms for analog type records
From: Ralph Lange <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: Bob Dalesio <[email protected]>, Ned Arnold <[email protected]>, Andrew Johnson <[email protected]>, Eric Norum <[email protected]>, Janet Anderson <[email protected]>, Jeff Hill <[email protected]>, Matej Sekoranja <[email protected]>, Ken Evans <[email protected]>, Benjamin Franksen <[email protected]>
Date: Thu, 03 Mar 2005 15:00:50 +0100
Hi all,

I find that for all analog type records, the fixed number of alarm limits and severities is a constraint that should be removed.

I would rather have the analog alarms organized like a breakpoint table, consisting of a series of ranges with a severity (and a status?) for each. The default would be no table, which is the complete range being "NO_ALARM".

Maybe some breakpoint table code and parsing can be re-used.

The hard part is probably that CA and the clients on the other end would have to reflect this structure, which is not a fixed-number set of attributes anymore. Rather an array of (value, value, (status?), severity) structures.

The other open question is: Changing alarm limits is not just setting a field anymore, it means reloading a breakpoint table. Is that acceptable? Must the alarm limits be writable through CA?

What do you think?
Ralph

--
Ralph Lange               [email protected]     Tel: +49 30 6392-2117
BESSY Controls Group      www.bessy.de             Fax:      ...   -4859



Navigate by Date:
Prev: Re: EPICS base V4: iocCore database Benjamin Franksen
Next: Announcing the core-talk mailing list Andrew Johnson
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: memory management Benjamin Franksen
Next: Announcing the core-talk mailing list Andrew Johnson
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·