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  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  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  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Recommendations for StreamDevice "architecture" flow
From: Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Wed, 5 May 2021 19:11:42 +0200
My 2cts:

Technically, these are all valid.
Question is always: What does the protocol look like? What are you trying to achieve? Is the device well-behaved?

In general:
FLNK means: *now*, as in immediately after.
Same SCAN period means: in the same interval, not necessarily in the same order (unless you use the PHAS field).
Your device protocol specifies if you need to keep a specific order or not.

Use parameters:
Many devices have similar commands that only differ in one token. Push that token from the record link to a generic protocol.
Especially when doing %() redirections, it is useful to have the "device" part of the record name as a parameter to use in those redirections.

Another technique I have seen:
Have the individual records scanned by one or multiple soft events, and add an event record for each that is triggering the swarm. Advantage: no fixed linking, but still a single SCAN field that changes the period for many records. (Easy to change scan periods for parts of the interface depending on the situation.)

Also interesting:
For a complex but fixed-order configuration, put the whole configuration into a single protocol. Fetch any configurable values from other passive records using the %() redirection. Initially hard-coded values can later easily be made configurable that way.

In most cases, how the records are triggered is not the most important aspect of your interface, and neither the aspect that needs the most time to implement. StreamDevice drivers are following the 90/10 principle: getting things working and your commands implemented is the fast part. Getting your implementation to be robust (reboot both ends, pull cables at any moment) and having the error handling done right is the part that often gets frustrating.

Cheers,
~Ralph

References:
Recommendations for StreamDevice "architecture" flow Wang, Andrew via Tech-talk

Navigate by Date:
Prev: Recommendations for StreamDevice "architecture" flow Wang, Andrew via Tech-talk
Next: RE: Recommendations for StreamDevice "architecture" flow Pearson, Matthew R. via Tech-talk
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  <20212022  2023  2024 
Navigate by Thread:
Prev: Recommendations for StreamDevice "architecture" flow Wang, Andrew via Tech-talk
Next: RE: Recommendations for StreamDevice "architecture" flow Pearson, Matthew R. via Tech-talk
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  <20212022  2023  2024 
ANJ, 05 May 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·