Experimental Physics and Industrial Control System
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
- Replies:
- Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
- References:
- [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
- Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
- Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Brian Bevins
- Navigate by Date:
- Prev:
Re: Changes to records during asynch processing Andrew Johnson
- Next:
FW: Problem with seq 2.0.4 Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: [Fwd: Re: Does DISP work for DB OUT links? Related question] Jeff Hill
- Next:
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024