EPICS Home

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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: AlarmHandler - filtering vs. HYST
From: "Ernest L. Williams Jr." <[email protected]>
To: Brian McAllister <[email protected]>
Cc: Terry Carlino <[email protected]>, [email protected]
Date: Fri, 14 Apr 2006 17:22:47 -0400
On Fri, 2006-04-14 at 15:03 -0400, Brian McAllister wrote:
> [ 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.
Seems like a nice addition. What version of ALH did you add this
feature?  Finally, could you submit a patch to the APS (Janet Anderson)
for review and possible inclusion into the main ALH distribution.





> 
> ----
> Brian McAllister                                   Senior Software Engineer
> [email protected]                      Bates Research & Engineering Center
> (617) 253-9537                                                Middleton, MA


References:
Re: AlarmHandler - filtering vs. HYST Brian McAllister

Navigate by Date:
Prev: Re: AlarmHandler - filtering vs. HYST Maren Purves
Next: Alarm Handler in Global mode in and outside the control room Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: AlarmHandler - filtering vs. HYST Maren Purves
Next: Re: AlarmHandler - filtering vs. HYST Terry Carlino
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024