Experimental Physics and
Industrial Control System

"J. Frederick Bartlett" <[email protected]> · Tue, 11 Feb 2003 09:55:51 -0600

> -----Original Message-----
>
> In most cases recGblResetAlarms should NOT be called.
>
> Let's review what recGblResetAlarms does (It also sets alarm mask
> but that is
> not important for this discussion).
>
> It sets
>
> stat = nsta    set status equal to new status
> sevr = nsev    set severity equal to new severity
> nsta = 0       set new status to 0
> nsev = 0       set new severity to 0
>
> What is assumed is that no more alarms will be raised from the time
> recGblResetAlarms is called until db_post_event is called for any
> field that the
>   record support process method monitors. recGblSetSevr changes
> the nsta and
> nsev fields NOT the stat and sevr fields. If something not connected with
> processing calls recGblResetAlarms then alarms connected with
> record processing
> may be lost.
>
> Fritz's question relates to issuing a db_post_event to a field
> that is not
> monitored by the record support module. The status and severity
> that will be
> associated with the db_post_event will be the status and severity
> related to the
> last time recGblResetAlarms was called, i.e. the last time the
> record was processed.
>
> In most cases this should be OK. If the db_post_event is for a field not
> monitored when the record is processed alarms should not be of
> interest. For
> example consider the aiRecord. It has a special routine that
> looks for field
> LINR being changed. If it detects a change it also checks to see
> if ESLO and
> EOFF change and if they change it calls db_post_event. If a CA
> client monitors
> these fields asking for severity and status it will get the
> status and severity
> from the last time the record was processed. Thus it could get
> the old status
> and severity even though they have changed because the record
> has started but
> not completed processing. I will maintain that the CA client
> should not be
> asking for status and severity for such fields. If it does it
> will also receive
> an event each time the status and severity change.
>
> If a record support module has a lot more "state" than normal
> records perhaps
> there might be a reason for code other than process to call
> recGblResetAlarms.
> But think hard before creating such record support.
>
> Marty Kraimer

Marty,

  Thanks for the clarification.  I was fairly certain that recGblResetAlarms
should not be called in the case that I cited but I was uncertain about the
relationship to alarms. Your explanation has clarified my understanding of
the alarm generation process.  What contributed to my confusion was the
appearance of recGblResetAlarms in the monitor function rather than the
alarm function of most records. That suggested that recGblResetAlarms was in
some manner associated with the "posting" of events rather than the issuing
of alarms. In retrospect I would consider that it would be better placed at
the end of the alarm function.

										Fritz

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System