Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 04 Jan 2000 17:18:49 +0100

Hello,

while testing the latest changes to the mbboDirect record, I noticed the
following, which seems to be a general problem.

Imagine two (or more) output records with soft support. They are chained
by their OUT links pointing to some field of the next record. The links
are PP and MS.

Now, if the severity of the first record changes during processing, this
change is NOT forwarded to the next record until it is processed the
next time. Instead the old severity is used. If the first record is a bo
with two state dependend severities, and if this record is always
alternating between one and zero, the second record will ALWAYS have the
wrong severity, namely the one from the last processing, not the
current.

The reason is that the record support code of most record types calls
recGblResetAlarms after calling the device support's write function. The
latter will call dbPutLink if it is a soft support. But when dbPutLink
sees the MS flag on, it sets the severity of the target record to the
source records's SEVR, which have not yet been updated (recGblSetSevr
sets only NSEV and NSTA). Only when the source record calls
recGblResetAlarms will STAT/SEVR be set to NSTA/NSEV, but then
processing of the target record is long over.

As a solution one could change dbPutLinkValue to use NSEV instead of
SEVR of the source record, i.e. change line 827 in dbAccess.c from

	recGblSetSevr(pdest,LINK_ALARM,psource->sevr);

to 

	recGblSetSevr(pdest,LINK_ALARM,psource->nsev);

How about that? Will this break other code?

BTW: The problem does not exist with input links because, if the input
link is PP and MS, the source record will have been processed completely
before dbGetLink evaluates the source record's STAT.

Ben
-- 
The Notorious Neb Nesknarf

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System