Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Tue, 11 Feb 2003 08:00:32 -0600

J. Frederick Bartlett wrote:

  I have a question concerning the use of the function recGblResetAlarms in
conjunction with the db_post_events function.
  I wish to raise a monitor event when selected fields of a record are
changed by a dbPutField call (usually via a channel access message).  The
fields are all marked for special processing -- the special(SPC_MOD)
attribute of the field has been set. The examples indicate that monitor
activation during the "process" phase clearly require an initial call to
recGblResetAlarms; however, when the change of value takes place outside of
a call to the record's process function, does recGblResetAlarms need to be
invoked?
 Fritz

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 assummed 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System