EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: EPICS Base Bug Report
From: [email protected]
To: EPICS Tech-Talk <[email protected]>
Date: Thu, 2 May 2002 14:06:22 +0200
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

Navigate by Date:
Prev: RE: 3.14 questions Ralph . Lange
Next: Re: EPICS Base Bug Report Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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: about VDCT John Maclean
Next: Re: EPICS Base Bug Report Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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 ·