Re: Generic EPICS IOCs

[Pete Jemian via Tech-talk <tech-talk at aps.anl.gov>]

Seems in the earlier days of the APS, many beam lines did this: built an IOC image that included EPICS support for any possible controls (hardware or software).  Worked well (or we would have abandoned it quickly).  One motivation for this practice was that we only had one OS (VxWorks) and one type of hardware (VME) on which to run an IOC.  The current trend is to have smaller IOCS focused on only a few support topics.

There are challenges to flexibility.  Some facilities might enjoy this, especially those that need many identically-configured IOCs.  An upgrade for a single instance of the IOC becomes the outlier in this model.  The custom IOC needs a non-standard boot.  This IOC exception must be managed so it is short-lived.  (If the exception remains for a long time, one could question the value of a common IOC image.)  Upgrade of the standard boot image had to consider all the special cases from each beam line.

At APS beam lines, it might be possible to prepare a common IOC image but it seems less likely to be used.  Most beam lines have custom IOCs such that the number of exceptions from a standard far exceeds the number that would use the standard.

Pete

On 1/16/2024 9:00 AM, Ralph Lange via Tech-talk wrote:
> On Tue, 16 Jan 2024 at 08:55, Anders Lindh Olsson via Tech-talk <tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:
>
>     I would have to mostly agree with Ralph (except perhaps on the e3 approach adding risk).
>
>
> That might have been too strong.
> Never having worked with e3 and after decades of building IOCs statically and (carefully) dynamically, I still don't trust on-demand loading at start-up time. I know that the e3 reliability numbers are excellent, so maybe it's an assumed risk or German angst.
>
>     ____
>
>     It's demonstrably possible to use a generic binaryfor your IOCs, but you are going to differentiate your software controllers regardless – as I understand it, you are just shifting the customisation from the IOC application to a container which wraps the IOC application. And if you intend to make these mostly static objects I don't quite see what the gain would be; you are likely going to have the equivalent of one definition/configuration per instance anyway. You will need to define addresses to instrumentation, you may want different thresholds, etc.
>
>
> Might be a misunderstanding. That's all part of the by-instance configuration, which is outside of the container.
>
> In the distant past, VME IOCs were adding the drivers for all hardware used at an installation into a single binary. Having just one (VxWorks) image for all IOCs removes a lot of complexity. The world was simpler back then...
> IMHO, the killer is the added code. VxWorks images were loadable objects with run-time linking: you could load and unload state machines etc. at any time on the instance - despite using a single image. (Some spectacular crashes may have contributed to my run-time linking concerns.)
>
> Cheers,
> ~Ralph

--
----------------------------------------------------------
Pete R. Jemian, Ph.D.                 <jemian at anl.gov>
Beam line Controls and Data Acquisition (BC, aka BCDA)
Advanced Photon Source,    Argonne National Laboratory
Argonne, IL  60439                    630 - 252 - 3189
-----------------------------------------------------------
      Education is the one thing for which people
         are willing to pay yet not receive.
-----------------------------------------------------------