Experimental Physics and Industrial Control System
|
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.
|
- Replies:
- Re: Generic EPICS IOCs Ralph Lange via Tech-talk
- References:
- Generic EPICS IOCs Knap, Giles (DLSLtd,RAL,LSCI) via Tech-talk
- Re: Generic EPICS IOCs Ralph Lange via Tech-talk
- Navigate by Date:
- Prev:
Re: Generic EPICS IOCs Ralph Lange via Tech-talk
- Next:
ADVimba CPU usage Sandeep Kumar Malu - STFC UKRI 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:
Re: Generic EPICS IOCs Ralph Lange via Tech-talk
- Next:
Re: Generic EPICS IOCs Ralph Lange 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 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|