Experimental Physics and
Industrial Control System

[email protected] (Janet B. Anderson) · Mon, 22 Sep 1997 15:24:13 -0500

> We are getting intermitent INVALID alarms from a rather loaded IOC
> (order 1000 records.) the file ALH-default.alhAlarm is filled with
> things like:
>  
> Fri Sep 19 13:13:19 1997 :  B_hv_TAC_2_L_TOP             NO_ALARM     NO_ALARM        NO_ALARM     NO_ALARM         0
> Fri Sep 19 13:13:19 1997 :  B_hv_TAC_3_R_BOT             NO_ALARM     NO_ALARM        NO_ALARM     NO_ALARM         0
> Fri Sep 19 13:13:19 1997 :  B_hv_TAC_4_L_BOT             NO_ALARM     NO_ALARM        NO_ALARM     NO_ALARM         0

The alarm handler should log all changes in alarm status and it does not put
a record into the alarm file if the initial alarm status is NO_ALARM, so there
should be 3 corresponding lines in the log file prior to these 3 lines for the
same channels with the alarm status different than NO_ALARM.

> 1) The alarms come and go on about a 30 second time scale. In other
> words, they clear themselves and reappear again.
>  
> 2) The alarms are always for many, many records, sometimes all of
> them.
>  
> 3) It's only this one IOC, even though we are running the same
> application on another IOC connected to the same subnet, that one with
> not as many channels.
>  
> 4) The alarm handler displays: <NO_ALARM,NO_ALARM><TIMEOUT,INVALID>
> for all of the alarms.

If the ioc and the alarm handler were slow connecting the status would
be <COMM,INVALID> not <TIMEOUT,INVALID>. The status TIMEOUT must be 
from the record or device support so it looks to me like the connection
problem is between the ioc and the hardware. 

You could change the 4th field of the alarm mask in the alarm configuration
file line for each channel to T, no acknowledge transient. Then the 
<NO_ALARM,NO_ALARM><TIMEOUT,INVALID> messages would not appear when
the alarms were clear.

> 5) I infer from the output above that the records themselves are not
> in an invalid state.
>  

Yes, they are no longer in an alarm state.

> Seems like the alarm handler is a bit too impatient about decidin if
> it has a connection to the channel. Does that sound right?  Is there a
> way to configure the alarm handler to avoid this?

We had a similar hardware connection problem with a piece of hardware here,
so we implemented the alarm configuration file feature, ALARMCOUNTFILTER,
to filter intermittant alarms.  Of course, one should always make certain
that they know what is causing intermittant alarms before they start
filtering them out.

Here is a description of the ALARMCOUNTFILTER syntax.

    $ALARMCOUNTFILTER <inputCount> <seconds>

       The line starting with $ALARMCOUNTFILTER is optional. It is required
       only when a user wants the alarm handler to filter the registration of
       alarms for an alarm channel. This line defines alarm count and seconds
       required for alarm registration.  To register as an alarm, an alarm
       channel must remain in alarm state for more than <inputSeconds> seconds
       OR the alarm channel must enter into an alarm state from a no-alarm
       state more than <inputCount> times within <inputSeconds> seconds.

Hope this helps.

Janet

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System