EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Link arrays / syntax
From: Andrew Johnson <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: EPICS Core Talk <[email protected]>
Date: Thu, 20 Oct 2005 11:03:30 -0500
Marty Kraimer wrote:

Are you saying that we should not implement block, process, and wait semantics as part of a link definition?

I am under the impression that the general concensus that it is a good idea and we were deciding semantics.

Am I wrong?

I'm *not* against providing control over synchronization and sequencing of links, especially when it comes to arrays of them, but I don't believe all of the "block, process and wait" attributes make sense when you're dealing with single links, especially when it comes to fields like SDIS and TSEL.

Now I'm probably only complaining about some aspects of block and wait here, since process obviously *is* a link attribute for the caPut/caGet link types. I also accept that we need the ability to control whether get/put operations on individual links cause the source record to wait for the target operation to complete. However the descriptions I've seen so far of what the "block, process and wait" attributes mean haven't been very clear.

I suspect that the process attribute of a caMonitor link type actually has a different meaning to that of a caGet (for caMonitor it controls processing of the source record when a monitor event occurs, not the processing of the target record) - am I right in that? If so, I would really want to use a different name for it, something like updateScan?

I *am* saying that the complex sequencing and synchronization controls should not be part of the basic link type itself, but are more logically part of the array of links that the calc and sequence records etc. actually implement. Instead of using an array of links, they could contains an array of structures, where each structure contains a link field plus some other fields that control the seq/sync controls for that link. This would allow the sequence record to have even more complex controls than calc, since it wants to allow the user to sequence input and output links together in groups maybe, insert delays and so on.

I'd also like to see the discussion of the capabilities of individual link types distinguished from that of the capabilities of the generic link interface. A process attribute controls a capability of CA and DB links, but means nothing to my xyzzy link type, so please don't make my link have to implement stuff it doesn't need.

- Andrew
--
English probably arose from Normans trying to pick up Saxon girls.

References:
[Fwd: Re: Link arrays / syntax] Marty Kraimer
Re: [Fwd: Re: Link arrays / syntax] Benjamin Franksen
Re: [Fwd: Re: Link arrays / syntax] Marty Kraimer
Re: Link arrays / syntax Ralph Lange
Re: Link arrays / syntax Marty Kraimer
Re: Link arrays / syntax Steve Lewis
Re: Link arrays / syntax Tim Mooney
Re: Link arrays / syntax Andrew Johnson
Re: Link arrays / syntax Marty Kraimer

Navigate by Date:
Prev: Re: alarm/severity Ralph Lange
Next: Re: alarm/severity Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Link arrays / syntax Ralph Lange
Next: Re: [Fwd: Re: Link arrays / syntax] Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  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 ·