At 9:03 PM +0100 2009/02/15, Bernd Schoeneburg wrote:
/Hi all,/
/I would like to announce and discuss some ideas for base
modifications. These are in detail:/
*3. Alarm Delay Field in all Records*
Beside the alarm limits we have a "HYST" in the analog records. Why
not also a "DLY" (delay). Some values are very unstable and have some
noise or over-swing. So a short time over/under the limit should be
allowed sometimes. Implementing this in the ioc has two advantages:
1.:It is analog to "HYST" which is a value-related hysteresis. "DLY"
is a time-related hysteresis. 2.:Sending a lot of good/no-good
messages to the clients could be avoided. This change is not so easy,
many things must be considered.
I would call it ADLY ("alarm delay'). And I suggest you use this new
field and another new one, ANUM ("alarm number"), to implement this
just the way ALH now does: do not raise an alarm unless there are ANUM
excursions outside HYST in ADLY seconds. I agree that it is good to
push this functionality into the record because: (a) it reduces CA
traffic; (b) keeps this vital information in the database which is the
responsibility of the IOC developer, rather than with the possibly
multiple instance and maintainers of ALH or other alarm clients. In
particular, GUIs will now benefit.
One disadvantage: it hides the behavior of the device: how do you know
whether the underlying, suppressed alarms are getting better or worse?
How would you know to adjust the hysteresis parameters? As you say,
"many things must be considered."