Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Tue, 02 Sep 2003 14:15:42 -0500

Brian Bevins wrote:
Does this really solve the original problem? When asynchronous
processing starts for the second put won't it overwrite what the first
put cpoied into AVAL?

Sorry I did not give the solution that works. I sent the message without looking
carefully. Here is what I meant to say.
Let's just consider just the boRecord.
Review: Problem is
1) record has value 0 and a 1 is written. The record starts the first phase of
record processing which is a request send result of VAL being 1 to the hardware
2) While PACT is true the value 0 is written to the record.
3) Asyn completion occurs.
4) Record is processed again. The result from VAL being 0 to the hardware
5) Asyn completes.
If a CA is monitoring the VAL field we would like two monitors
1) VAL=1 is returned. Status, Severity, Time stamp are all the result of VAL=1
2) VAL=0 is returned. Status, Severity, Time stamp are all the result of VAL=0.

How to accomplish this:
VAL is declared special(SPC_MOD).
This means the record support will be notified both before and after VAL is
written. It does the following if it finds PACT=TRUE when special is called.
It keeps three additional fields. Call them SVAL, NVAL, USEN (Save Value, New
Value, and Use New). When special is called before the put it sets SVAL=VAL.
When called after the put it compares VAL and SVAL, i.e. did a new value get
written to the record. If VAL!=SVAL it sets NVAL=VAL, VAL=SVAL, and USEN=true.
When asyn completion occurs then just before recGblFwdLink is called, i.e. after
monitors are raised and if USEN=true then set VAL=NVAL and set USEN=0.
Example for boRecord with initial value=0, a put of 1, and then a put of 0.
1) The put of 1 occurs. asyn processing starts. VAL=1 is used to send a value to
hardware.
2) The put of 0 occurs:

a) special is called before VAL is changed. special sets SVAL=VAL=1

b) special is called after VAL is set to 0. special finds VAL=0 != SVAL=1.

Thus it sets NVAL=VAL, VAL=SVAL, and USEN=1.

3) asyn completion occurs

a) Normal asyn completion occurs.

VAL is 1 which is the value from the initial put.

b) Just before recGblFwdLink is called, record support

sets VAL=NVAL=0 and USEN=0

4) Because the put was done while PACT is true and the record is passive it will
be processed again
5) asyn start is performed. VAL is 0 which is from the second put.
6) asyn completion occurs. Since USEN=0 nothing is done with SVAL.
The above implements caching puts, i.e. if multiple puts are done between asyn
start and asyn completion then only the last value is saved in NVAL.
Marty

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System