EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: EPICS Base Bug Report
From: Marty Kraimer <[email protected]>
To: [email protected]
Cc: EPICS Tech-Talk <[email protected]>
Date: Thu, 02 May 2002 09:03:54 -0500
Ralph wrote:

> Possible fixes:
>
>  - dbPutField does not set the PUTF field if the record is disabled.
>  - dbPutLinkValue checks PACT instead of or in addition to PUTF to
>    determine an active asynchronous processing.
>
> Looking at the limited use of the PUTF field in EPICS base I would
> suggest throwing out this field completely. At least in 3.14 - to make
> more room for C++ code.


PUTF was created for the following reason:

If a CA client does multiple writes to an asynchronous record the record can easily be put in the following state:

1) The VAL field has the last value the client wrote.
2) The value written to hardware is the value from the 2nd to last value the client wrote.

Thus getting rid of PUTF might not be a good idea.

Looking briefly at the dbAccess code perhaps a slight modification of Ralph's first suggestion is the best fix. Let dbProcess set PUTF false if it finds the record disabled (no need to duplicate the code to see if the record is disabled). This seems to be consistant with what it means to disable a record.

When a record is disabled the VAL field can be changed by database links. When the record is enabled it is not automatically processed but waits for the next time something processes the record. Thus puts from CA client will have the same effect as database puts.

Marty Kraimer

[email protected] wrote:

This is an EPICS bug report.

Affected versions:

Probably all recent EPICS versions.


Likely symptom:

After disabling, writing a value, and reenabling a passive record using
Channel Access puts to its DISA field (e.g. as part of a snapshot file
restore or a bumpless reboot procedure) local DB OUT links with
attribute PP will continue to write the value to the record, but won't
process it.

As soon as some application does a CA put to the record, things get back
to normal, i.e. local DB OUT links with PP attribute will write the
record value and process.


Analysis:

When the record's value is written while it is disabled, its PUTF field
is set (in dbPutField), while the code that usually resets the field (in
recGblFwdLink) is not executed because the record is disabled.

After the record is reenabled, any DB OUT link pointing to it will
interpret the PUTF field still being TRUE (in dbPutLinkValue) as an
asychronous record processing being active. So it will register an apply
for reprocessing by setting the RPRO field instead of instantaneously
triggering processing of the destination record. As the record is not
active, is is never processed.

Any CA put to the record doesn't care about the PUTF field, processes
the record and after PUTF is reset (in recGblFwdLink) subsequent DB
links to the record will work as expected.


Workaround:

Setting the OUT link attribute to CA instead of PP in the database that
tries to trigger the record will yield the desired behaviour regardless
of the record's disable history.


Possible fixes:

 - dbPutField does not set the PUTF field if the record is disabled.
 - dbPutLinkValue checks PACT instead of or in addition to PUTF to
   determine an active asynchronous processing.

Looking at the limited use of the PUTF field in EPICS base I would
suggest throwing out this field completely. At least in 3.14 - to make
more room for C++ code.

As I'm not too well aware of dangerous side effects I would like the APS
database gurus to decide how this is to be solved.


Happy processing,
Ralph



Replies:
Re: EPICS Base Bug Report Marty Kraimer
References:
EPICS Base Bug Report Ralph . Lange
Navigate by Date:
Prev: EPICS Base Bug Report Ralph . Lange
Next: Channel Archiver graber
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: EPICS Base Bug Report Ralph . Lange
Next: Re: EPICS Base Bug Report 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 
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 ·