Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020 
<== Date ==> <== Thread ==>

Subject: RPRO inconsistency
From: Michael Davidsaver <mdavidsaver@gmail.com>
To: EPICS core-talk <core-talk@aps.anl.gov>, Andrew Johnson <anj@aps.anl.gov>, Ralph Lange <Ralph.Lange@gmx.de>
Date: Sun, 21 Jan 2018 17:46:44 -0800
I'm almost certain that this is an easy fix, but it's subtle enough I'd like to get
a second opinion before making changes.  In particular, I'm wondering about
interactions with dbNotifyCompletion().


I notice that dbPutField() sets RPRO=1 when PACT=1, but dbProcess()
itself does not.  This means that dbPutField() to a record w/ PACT=1
is queued for reprocessing, but async records processed indirectly
(via DB link) are not queued for reprocessing.

A database which demonstrates the process is the following.
I think that "tst:val.VAL" should _eventually_ be 2.
Currently it's 1, with the change below, it's 2.

> record(fanout, "tst:fout") {
>   field(PINI, "RUNNING")
>   field(LNK1, "tst:calc")
>   field(LNK2, "tst:calc")
>   field(TPRO, "1")
> }
> 
> record(calcout, "tst:calc") {
>   field(INPA, "tst:calc")
>   field(CALC, "A+1")
>   field(ODLY, "0.1")
>   field(OUT , "tst:val")
>   field(TPRO, "1")
> }
> 
> record(longin, "tst:val") {
>   field(TPRO, "1")
> }

I think the simplest fix is:

> diff --git a/src/ioc/db/dbAccess.c b/src/ioc/db/dbAccess.c
> index 71e25310f..6376dc46d 100644
> --- a/src/ioc/db/dbAccess.c
> +++ b/src/ioc/db/dbAccess.c
> @@ -526,6 +526,8 @@ long dbProcess(dbCommon *precord)
>          if (*ptrace)
>              printf("%s: Active %s\n", context, precord->name);
>  
> +        precord->rpro = TRUE;
> +
>          /* raise scan alarm after MAX_LOCK times */
>          if ((precord->stat == SCAN_ALARM) ||
>              (precord->lcnt++ < MAX_LOCK) ||

Replies:
Re: RPRO inconsistency Johnson, Andrew N.

Navigate by Date:
Prev: Jenkins build is back to normal : epics-base-3.15-win64 #331 APS Jenkins
Next: areaDetector developers meeting @ APS Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020 
Navigate by Thread:
Prev: Jenkins build is back to normal : epics-base-3.15-win32-test #143 APS Jenkins
Next: Re: RPRO inconsistency Johnson, Andrew N.
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020 
ANJ, 22 Jan 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·