Re: Generic EPICS IOCs

[Ralph Lange via Tech-talk <tech-talk@aps.anl.gov>]

On Tue, 16 Jan 2024 at 08:55, Anders Lindh Olsson via Tech-talk <tech-talk@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 binary for 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