Re: EPICS Base Bug Report

[Marty Kraimer <mrk@aps.anl.gov>]

The change to fix the problem Ralph reported is to have dbProcess set putf=0 if 
it finds the record disabled. For the latest 3.13 release the change is

diff -c -r1.89.4.6 dbAccess.c
*** dbAccess.c  2002/04/08 14:40:59     1.89.4.6
--- dbAccess.c  2002/05/02 20:09:15
***************
*** 607,612 ****
--- 607,613 ----
                if(*ptrace) printf("disabled:  %s\n",precord->name);
                /*take care of caching and notifyCompletion*/
                precord->rpro = FALSE;
+               precord->putf = FALSE;
                if (precord->ppn) dbNotifyCompletion(precord);
                /* raise disable alarm */
                if (precord->stat==DISABLE_ALARM) goto all_done;


This change will appears in next release of both 3.13 and 3.14.

Marty Kraimer

Marty Kraimer wrote:

> 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
>
> Ralph.Lange@mail.bessy.de 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