EPICS Controls 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  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: RPRO inconsistency
From: "Johnson, Andrew N." <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Tue, 23 Jan 2018 02:12:32 +0000
Hi Michael,

I think you are right about the subtlety of this issue, I seem to remember wanting to make that change many years ago but was persuaded (or I discovered) it would be a bad idea. I think it relates to preventing infinite loops using DB links — if you make that change I suspect a record that FLNKs to itself will eat up 100% of a UP CPU.

- Andrew

-- 
Sent from my iPad

> On Jan 21, 2018, at 8:46 PM, Michael Davidsaver <[email protected]> wrote:
> 
> 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 Michael Davidsaver
References:
RPRO inconsistency Michael Davidsaver

Navigate by Date:
Prev: areaDetector developers meeting @ APS Mark Rivers
Next: Re: RPRO inconsistency Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RPRO inconsistency Michael Davidsaver
Next: Re: RPRO inconsistency Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
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 ·