Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: AlarmHandler - filtering vs. HYST
From: "Brian McAllister" <mcallister@mit.edu>
To: Terry Carlino <carlino@jlab.org>
Cc: tech-talk@aps.anl.gov
Date: Fri, 14 Apr 2006 15:03:55 -0400
[ This is a bit late, just catching up. ]

>>> On 4/7/2006 at 12:31:30 EDT, Terry Carlino wrote:

  > Probably the best way to compensate for this problem. thanks.

  > Steve Lewis wrote:

  >> Try this (one of the best features of ALH): use
  >> 
  >> $ALARMCOUNTFILTER count seconds

This will help you, but (IMO) the best solution for any alarm hovering
around a transition value is almost always to set HYST appropriately in the
record. I realize you would have to convince others to modify the databases
for this.

The ALH filters ignore alarms regardless of the size of the change that
induced them, whereas HYST allows you to ignore only changes that are "not
significant".

HYST also has the advantage of controlling alarms at the source, so if you
use alarm status for other purposes, such as colors or visibility on
displays, these will also be "filtered" and users won't get used to
ignoring them if they flash.

You should look at the "NOACK Transient" mask in ALH.  With this set, when
the PV goes out of alarm ALH will stop beeping at you.

[ minor rant follows ]

I believe that *all* analog ADC inputs with alarms should have HYST>0 (as
well as MDEL/ADEL>0, for efficiency).  The minimum value for HYST should be
just over 1 bit, so you won't generate alarms if the ADC is sitting on a
bit transition.

I also believe that alarm limits, especially MINOR alarms, should be
influenced by operational reality as well as engineering design.  If the
normal value of an analog input is close enough to an alarm limit to
generate alarms when no action is actually required, that limit should
probably be changed.

Based on personal experience I can state that any significant number of
"nuisance" alarms will lead to users becoming less reactive to real alarms.

We were having enough issues with operators silencing ALH "forever" (so
they wouldn't be annoyed by "false" alarms) that I modified ALH to put a
black border around the button on the screen so you could tell it was
silenced without opening the alarm window.

----
Brian McAllister                                   Senior Software Engineer
mcallister@mit.edu                      Bates Research & Engineering Center
(617) 253-9537                                                Middleton, MA

Replies:
Re: AlarmHandler - filtering vs. HYST Steve Lewis
Re: AlarmHandler - filtering vs. HYST Maren Purves
Re: AlarmHandler - filtering vs. HYST Ernest L. Williams Jr.
Re: AlarmHandler - filtering vs. HYST Terry Carlino

Navigate by Date:
Prev: AW: NewFocus 8752 Maximilien J. Collon
Next: Re: AlarmHandler - filtering vs. HYST Steve Lewis
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: RE: NewFocus 8752 Mark Rivers
Next: Re: AlarmHandler - filtering vs. HYST Steve Lewis
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·