EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: alh
From: Rod Nussbaumer <[email protected]>
To: [email protected]
Date: Tue, 30 May 2017 09:27:48 -0700
I think the behavior that Rolf was questioning is about the way ALH stops annunciating the alarm state. To register as an alarm, the PV satisfies the criteria that it transitions to the ALARM state the prescribed number of times within the prescribed time.

To exit that alarm registration, would logically seem to require a different condition, such as no (or fewer than the prescribed number) transitions to ALARM state. If the PV simply continues the same actions that got ALH to register an alarm, it doesn't seem logical that de-registering an alarm should occur when the PV continues to do what caused the original registration of an alarm. Moreover, the ongoing toggling of the alarm state of the record will once again cause ALH to register a new alarm, even though nothing about the record behavior has really changed.

Does someone rely on this behavior for some use case, or would it be considered as incorrect behavior?

Rolf posed this question in the context of writing an ALH work-alike, and the first order requirement is that it duplicate the behavior of ALH. In this instance, I question whether that means duplicating what is essentially a bug.

Rod Nussbaumer
TRIUMF
Vancouver, Canada



On 05/28/2017 02:52 AM, Andreas Lüdeke wrote:

 > I have an alarm PV which needs no acknowledgement and is configured
with an input count filter:

 $ALARMCOUNTFILTER 3 8

 > The alarm PV changes from "in alarm" to "out of alarm" once/second
for a long time.

 I see the following behaviour in alh:

    6 seconds after the alarm starts toggling, the PV goes into alarm.
    After another 6 seconds, the PV goes out of alarm.

The behaviour is as intended, if the PV changes once per second its state.
Because you've specified the filter "3 8":
it goes in the alarm state, if the alarm either stays for 8 seconds,
or if it enters an alarm state three times within 8 seconds.

This PV enters an alarm state every two seconds, so after six seconds it raised an alarm the third time.

If you would change the filter to for example

$ALARMCOUNTFILTER 5 8

then it would never go into alarm (if the PV sticks to its behaviour).
When it would stop toggling and stays instead into alarm, an alarm would be raised after 8 seconds.
If it would change its state more frequent, an alarm would be raised as well.

I hope that helps to clarify the ALARMCOUNTFILTER.

Cheers from Switzerland :-)
Andreas



References:
Re: alh Andreas Lüdeke

Navigate by Date:
Prev: RE: Configuring multiple ports with variable port numbers for StreamDevice Mark Rivers
Next: Use case for ao record HOPR != DRVH or LOPR != DRVL? J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: alh Andreas Lüdeke
Next: epicsqt Siddons, David
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·