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: Andrew Johnson <[email protected]>
To: Ralph Lange <[email protected]>
Cc: [email protected]
Date: Thu, 10 Dec 2009 12:47:51 -0600
Hi Ralph,

On Thursday 10 December 2009 10:28:39 Ralph Lange wrote:
>
> Real world example:

Sorry, I do understand the desire to be able to do a put without processing, 
my skepticism was with the possibility of actually doing it, because we'd need 
to do a "put without proc" on initial connection but a "put with proc" on 
later record processing.  That needs changes to the CA protocol to add the 
proc flag as you realize; we couldn't even do it using a {process:true} field 
modifier since that's a different channel.

> 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.

Right, not worth bothering with.

> 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)

We can implement the choice of whether to process the target or not after a 
put by using a field modifier.  The default should still be determined by the 
field's PP setting, but could be overridden by appending {process:true} or 
{process:false} to the field name.  However CAv3 doesn't have the ability to 
tell the target whether to process or not after a put, so your SOR/POR 
distinction is not currently possible.

I would also add that if an OUT link has never been activated it doesn't know 
what data to send (or even what data type to use), which is why I much prefer 
ROR = Resend-On-Reconnect, it describes the actual behavior of the current 
code better.

> 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).

I could see some applications using a DB flag, presumably it would generate a 
warning or error message at iocInit time when the links get resolved and would 
prevent the link from being presented to CA for resolution.  It isn't really 
necessary though, it just provides a hint to a later developer that there's 
some reason that these two records must be located in the same IOC.

> 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.

Still needs CAv3 to be able to send a Process bit with puts, with all the 
backwards compatibility issues that raises.  My field modifier idea above 
doesn't suffer from that.

> To keep compatibility, on input links .CP would translate to .CA.P and
> .CPP to .CA.PP (sorry to be obvious).

FYI the way the link flag parser currently works we can't have single letter 
options unless that letter doesn't appear in any other flags.  Basically if 
one flag name is a substring of another the two must be strictly exclusive; we 
always search for the longest first since this parsing is currently done using 
strstr() on the part of the link string following the PV name.

I want to replace the existing link syntax with a JSON-encoded object instead, 
which will give us much more flexibility and better parsing, thus I don't 
recommend spending too much time thinking about or enhancing the existing link 
syntax.

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


References:
Re: CA link behavior Andrew Johnson
Re: Fwd: CA link behavior Andrew Johnson
Re: Fwd: CA link behavior Ralph Lange

Navigate by Date:
Prev: OMS MAXv driver Mark Rivers
Next: EPICS database comparison Pam Gurd
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 Ralph Lange
Next: aSub and C++ Simon Hoyle
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 ·