On Wed 09 Dec 2009 17:18:10 Andrew Johnson wrote:
On Wednesday 09 December 2009 15:06:23 Ralph Lange wrote:
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).
[...]
I do not plan to make the above change, and in fact I will probably comment
out both lines, because in the future I think we should look at adding a flag
(ROR = Resend On Reconnect?) to output links to allow users to turn this
behavior on. I can see it as being useful in some cases. I'm not so sure
about the idea of a put without causing processing though...
Hi Andrew (did you shovel your way into work?),
Real world example:
Consider a setup where record C on ioc2 is a device (e.g. power supply)
set point connected to hardware, while B on ioc1 is part of a
convenience layer on a soft IOC (e.g. converting field to magnet
current) that writes to the device. In addition to B, C is also being
shown in detail panels and being archived, so rebooting ioc2 should be
bumpless.
The general guide line would be: After a reboot the system should be as
close to the prior state as possible, but without any additional record
processing. To meet that goal, even though B.OUT should normally process
C when fired, after a reboot of ioc2 it should only put the value,
without processing C.
On the other hand, as the workaround is simple and reliable (put C in
auto-save/restore pass 1), I'm not sure how much effort can be justified.
Hm... I would really like the link spec being able to specify processing
the target on OUT links, too (instead of using the target field's PP
flag), so that the CA related flag set would become:
CA Force link to use CA
CP Force CA, process receiving record (both INP and OUT links)
CPP Same, but only if receiving record is passive (INP and OUT)
SOR Send on reconnect
POR Process on reconnect (only passive if CPP is true)
Actually, things could then even be made more orthogonal:
<none>/CA Auto link [default]
/ Force CA link
<none>/P/PP No processing [default]
/ Process receiver
/ Process receiver if Passive
<none>/SOR/POR/PPR No reconnect action [default]
/ Only send on reconnect
/ Send and process receiver on reconnect
/ Send and process rec. on reconnect if Passive
For completeness, DB could be added for the first set to force local
resolution (I don't see a use case, though).
The second set would be valid for DB and CA links.
The third set would be valid for CA links only.
All sets would be valid for INP and OUT links.
To keep compatibility, on input links .CP would translate to .CA.P and
.CPP to .CA.PP (sorry to be obvious).
Ralph
- Replies:
- Re: Fwd: CA link behavior Andrew Johnson
- References:
- Re: CA link behavior Andrew Johnson
- Re: Fwd: CA link behavior Dirk Zimoch
- Re: Fwd: CA link behavior Ralph Lange
- Re: Fwd: CA link behavior Andrew Johnson
- Navigate by Date:
- Prev:
Re: Odd widget layout in EDM on OS X Eric Norum
- Next:
OMS MAXv driver Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Fwd: CA link behavior Andrew Johnson
- Next:
Re: Fwd: CA link behavior Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|