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 as a daemon or service
From: Terry Carlino <carlino@jlab.org>
To: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Fri, 07 Apr 2006 12:31:30 -0400
Probably the best way to compensate for this problem. thanks.

Terry

Steve Lewis wrote:

Try this (one of the best features of ALH): use

$ALARMCOUNTFILTER count seconds

on each PV. Basically, it suppresses the triggering of the alarm until at least 'count' transitions have occurred within a window 'seconds' or the alarm level must hold for 'seconds' long. So if you get a 'nuisance' MINOR once every 30 seconds that lasts about 10 seconds, try count=2, seconds=60. Great for water bubbles in your cooling system...

Another techniques is to set up a big chain of dfanout records to push alternately MINOR or NOALARM to the SEVR field (HIGH, HIHI, whatever you are using) based on a top-level bo record with labels like "TUNE" and "RUN".


At 8:08 AM -0400 2006/04/05, Terry Carlino wrote:


As an AlarmHandler user it has always struck me that there should be a better way to manage alarms. In the real world it is quite common to have a device sitting just on the edge of the MINOR alarm point, creating nuisance alarms. We do not generally manage alarms by actively changing HIGH or LOW, since these are set by system experts. This leaves the user with the choice of disabling the alarm, which means that if the device reaches the MAJOR parameter no alarm will be heard or dealing with the nuisance alarms. Bad enough when a single channel behave such. When you have thousands of channels, not uncommon for a few to have this problem, especially during times of general machine instability, such as start up. It would be nice to be able to separately acknowledge or bypass MINOR alarms, a kind of "yeah we know we need to look at you, you're alright for now call us when you get to the MAJOR setpoint.

Terry



begin:vcard
fn:I. Terry Carlino
n:Carlino;I. Terry
org:Thomas Jefferson National Accelerator Facility;Accelerator Operations
email;internet:carlino@jlab.org
title:Accelerator Operator
x-mozilla-html:TRUE
version:2.1
end:vcard


References:
AlarmHandler as a daemon or service Ernest L. Williams Jr.
Re: AlarmHandler as a daemon or service Matthias Clausen
Re: AlarmHandler as a daemon or service Ernest L. Williams Jr.
Re: AlarmHandler as a daemon or service Matthias Clausen
Re: AlarmHandler as a daemon or service Terry Carlino
Re: AlarmHandler as a daemon or service Steve Lewis

Navigate by Date:
Prev: Re: Button push confirmation john sinclair
Next: RE: Button push confirmation - an implementation with no hardcoded PVs Tang, Johnny Y.
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: AlarmHandler as a daemon or service Steve Lewis
Next: Re: AlarmHandler as a daemon or service 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 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·