EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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>  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> 
<== Date ==> <== Thread ==>
Subject: Re: Generic EPICS IOCs
From: Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Mon, 15 Jan 2024 17:26:38 +0100
My 2cts...

What you describe seems to be pretty much the container equivalent of system packages that install IOC binaries. (In addition to the IOC binary, the image will need to provide DBD information for the compiled-in modules.)

I would expect issues and maybe limitations roughly in the same areas, then, especially regarding usability for other facilities. A lot depends on how exactly you define "class of device".

Some roughly sorted thoughts:
  • Managing the combinations of EPICS Support modules that are tested together is an issue. The more variety you allow, the more complicated to maintain/support users.
  • Are the provided IOC binaries extendable at run time? Device Support libraries are almost plug-ins. Still, creating the IOC binary needs code to be generated and linked in. A true plug-in mechanism that doesn't need recompiling is possible (see E3), but adds risk.
  • Building a stack of images (each one with one more Device Support and the resulting IOC binary/DBD) is possible, but fixes the set of modules and their order.
  • Subroutine records? Sequencer state machines? Server-side filters? Anything that adds code will likely need its own IOC image ... these won't be very generic, anymore.
    Maybe a sample Containerfile showing how to use the Generic IOC image to build a (more) specific IOC image on top would be worthwhile.
I generally like the idea, for sure.
But with the amount of code that can be generated, added and needs to be linked in... "viable for use in any facility" might be challenging.

This is comparable to the binary distribution for the OPC UA Device support: that started with distributing IOC binaries, but it didn't work. ( "I need iocStats." "I need the <whatever> record." "I need QSRV/pvAccess." "How do I add a state machine?"...) The current way of distributing shared-library plus DBD leaves compiling the final IOC binary to the users, allowing them to add their specific code.

Cheers,
~Ralph
Replies:
Re: Generic EPICS IOCs Anders Lindh Olsson via Tech-talk
References:
Generic EPICS IOCs Knap, Giles (DLSLtd,RAL,LSCI) via Tech-talk
Navigate by Date:
Prev: Channel Finder using PV Access CAOUEN Loïc via Tech-talk
Next: Re: Generic EPICS IOCs Anders Lindh Olsson 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  2021  2022  2023  <2024> 
Navigate by Thread:
Prev: Generic EPICS IOCs Knap, Giles (DLSLtd,RAL,LSCI) via Tech-talk
Next: Re: Generic EPICS IOCs Anders Lindh Olsson 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  2021  2022  2023  <2024> 
ANJ, 16 Jan 2024 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·