Experimental Physics and
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.
|ANJ, 10 Aug 2010||
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·