Re: Generic EPICS IOCs

[Anders Lindh Olsson via Tech-talk <tech-talk at aps.anl.gov>]

I would have to mostly agree with Ralph (except perhaps on the e3 approach adding risk).

 

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.

 

For a larger facility where you have multiplicity in equipment (e.g. several instances of the same type of device), or if you use modular electronics, you will benefit from having some concept of generic types, but that's as far as I would take it.

 

On top of what Ralph already says about needing to "opt-in" to functionality, there is quite likely to be infrastructural and/or generic site-specific needs that would be hard to extend these generalised containers with. What if my site needs extensions to IOC runtime monitoring, or if we use ChannelFinder while you do not? How do I modify IOC access protection? How would you go about implementing the same change in every IOC or container?

 

 

Cheers

A

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Reply to: Ralph Lange <ralph.lange at gmx.de>
Date: Monday, 15 January 2024 at 17:37
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Generic EPICS IOCs

 

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