EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: some field definitions
From: Andrew Johnson <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: Core-Talk <[email protected]>, "Dalesio, Leo" <[email protected]>
Date: Mon, 27 Apr 2009 18:12:54 -0500
On Monday 27 April 2009 09:44:41 Marty Kraimer wrote:
>
> Note that when the request was made to implement put notify I was
> horrified about what this would  take to implement. It is really a mess.
>
> Note also that mrkSoftTest/iocBoot/iocput tests put notify.

I don't think this has anything to do with putNotify, it's simpler than that.

However after actually testing out my patch (thanks to Tim for prompting some 
particular experiments) I realize that as written it just allows infinite 
loops to be made without the need for even asynchronous processing.

I can see that setting RPRO in dbPutField() is essential to ensure that an 
external put to a record that is waiting for the second half of asynchronous 
processing will cause the record to be processed again to handle the new 
field value.  However I'm having trouble understanding why dbPutLinkValue() 
ever needs to set RPRO.

Given this database:

record(ao,"$(user):lo1")
{
    field(OUT,"$(user):lo2 PP")
    field(TPRO,1)
}
record(ao,"$(user):lo2")
{
    field(OUT,"$(user):lo1 PP")
    field(TPRO,1)
}

the existing code does this when I do a caput to anjHost:lo1:

CAS-client: Process anjHost:lo1
CAS-client: Process anjHost:lo2
scanOnce: Process anjHost:lo1
scanOnce: Process anjHost:lo2
scanOnce: Active anjHost:lo1

It's rather hard to explain why both records should process twice, but they do 
because of the PUTF sets RPRO test in dbPutLinkValue().

Could it be something to do with preventing external interference in 
processing inside the database?  I guess if you had two records A (periodic) 
which processes B (async), and the user pokes B directly, you'd want the 
periodic scan to be able to reprocess B if the period arrives while B is 
still busy.

This needs more thought, but that might explain why.  Got to go now,

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

Replies:
Re: some field definitions Marty Kraimer
References:
Re: some field definitions Andrew Johnson
Re: some field definitions Marty Kraimer

Navigate by Date:
Prev: Re: some field definitions Tim Mooney
Next: Re: some field definitions Marty Kraimer
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: some field definitions Marty Kraimer
Next: Re: some field definitions Marty Kraimer
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·