Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Changes to records during asynch processing
From: Marty Kraimer <mrk@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Date: Tue, 02 Sep 2003 08:49:33 -0500
Some further thoughts about what should happen if a put request is made between the start and completion of asynchronous processing.

One suggestion was that all such puts should be queued. I do not like this because it can a very heavyweight operation. I maintain that the existing semantics are mostly correct but a bug is present.

An example of the bug is: A boRecord has the value 0, The value 1 is written and before asynchronous completion occurs the value 0 is written. At present No CA monitors will be issued. If the record is synchronous two monitors will be issued, i.e. one with tha value 1 and a second with the value 0.

I claim that the only fields which present this problem are the VAL (or closely related fields) of output records. In particular for the records in base only the VAL fields of the ao, bo, longout, and mbbo records are a problem.

Brief Explaination:

dbAccess:dbPut, not record support, calls db_post_event for most field changes. A VAL field with pp(TRUE) is the only exception. In this case record support is expected to call db_post_event.
Since input records normally provide a new value to VAL, the put value is overriden when the record is processed, because VAL will receive a new value. A soft record with a NULL INP is an exception but then the record is synchronous.


Thus only the VAL field of output records are a problem.

Here is how the bug can be fixed.
Let's consider the boRecord.

Review: Problem is

1) record has value 0 and a 1 is written. The record starts the first phase of record processing. The RVAL obtained from VAL=1 is sent 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 RVAL obtained from VAL=0 is sent 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.


At present NO monitors are send because each time record completion occurs VAL is 0. When record support compares VAL with MLST they are always equal and db_post_event is not called.


Here is a way to fix the bug.

The VAL field is declared special(SPC_MOD).

This means the record support will be notified both before and after VAL is written. It could then do the following if it finds PACT true

Keep the value being written somewhere but leave VAL with the original value.

When asyn completion occurs do as normal until the end. After calling db_post_event it sets VAL equal the the value it saved. Thus when the second process starts the field has the value corresponding to the second put.


Marty Kraimer





Replies:
Re: Changes to records during asynch processing Tim Mooney
References:
Does DISP work for DB OUT links? Benjamin Franksen
Re: Does DISP work for DB OUT links? Marty Kraimer
Re: Does DISP work for DB OUT links? Benjamin Franksen
Re: Does DISP work for DB OUT links? Marty Kraimer
Re: Does DISP work for DB OUT links? Related question Benjamin Franksen
Re: Does DISP work for DB OUT links? Related question Marty Kraimer
Changes to records during asynch processing Benjamin Franksen
Re: Changes to records during asynch processing Marty Kraimer
Re: Changes to records during asynch processing Benjamin Franksen

Navigate by Date:
Prev: Home signal does not affect the .ATHM field of the motor record Rok Sabjan
Next: Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Brian Bevins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: Changes to records during asynch processing Benjamin Franksen
Next: Re: Changes to records during asynch processing Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·