EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  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: Fwd: CA link behavior
From: Ralph Lange <[email protected]>
To: [email protected]
Date: Wed, 09 Dec 2009 16:06:23 -0500
Hi,

I agree with Dirk's statement.

I would like to add, though, that currently if the D.INP link is A.CP (or D is passive and D.INP is A.CPP), D *will* get processed when the CA link is set up, independent from its PINI value. Reason: .CP and .CPP input links are implemented as CA monitors, and will get a value when the connection comes up. At that point, that first incoming value update is not distinguished from later updates, and the record is processed.

Again: I agree with Dirk that D should probably just be initialized, not processed on reboot of ioc2. But I'm not sure if that can be implemented easily (records may have many .CP inputs, so checking UDF is not sufficient), and I want to point out this would introduce a serious change in behavior, that could possibly break many existing databases.

I can see the unexpected string type link behavior possibly being intended to do something like an auto-save/restore on record C. This could be an interesting feature, if (and only if) it is independent from data type (obviously) and configurable (which requires a CA protocol change to allow the link spec to define target record processing - instead of the PP option of the target field now used for that purpose).

Cheers,
Ralph


On Wed 09 Dec 2009 4:58:26 Dirk Zimoch wrote:
Hi Andrew,

My personal opinion is that a record which is not processed should not "do" anything. That means it should not cause other records to process and should not change their value. I think the original idea behind processing a record is that this is the only time where a record is "active". Maybe apart from the time when it initializes. But even then it should not process other records.

Let's assume this situation:
ioc1:
A
B.OUT-> C

ioc2:
C
D.INP -> A

I think the "correct" behavior is:
When ioc2 reboots, C becomes INVALID/UDF and only gets a copy of B when B processes. D gets initialized with a copy of A. Neither C nor D gets processed unless they have PINI set.

Dirk


Replies:
Re: Fwd: CA link behavior Andrew Johnson
References:
Re: CA link behavior Andrew Johnson
Fwd: CA link behavior Geoff Savage
Re: Fwd: CA link behavior Andrew Johnson
Re: Fwd: CA link behavior Dirk Zimoch

Navigate by Date:
Prev: Re: EDM on Cygwin Ernest L. Williams Jr.
Next: Odd widget layout in EDM on OS X Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  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: Fwd: CA link behavior Dirk Zimoch
Next: Re: Fwd: CA link behavior Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·