Experimental Physics and
Industrial Control System
| 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: | Tue, 16 Jan 2024 16:00:21 +0100 |
On Tue, 16 Jan 2024 at 08:55, Anders Lindh Olsson via Tech-talk <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 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
~Ralph
- Replies:
- Re: Generic EPICS IOCs Pete Jemian via Tech-talk
- References:
- Generic EPICS IOCs Knap, Giles (DLSLtd,RAL,LSCI) via Tech-talk
- Re: Generic EPICS IOCs Ralph Lange via Tech-talk
- Re: Generic EPICS IOCs Anders Lindh Olsson via Tech-talk
- Navigate by Date:
- Prev: Re: ADVimba CPU usage Mark Rivers via Tech-talk
- Next: Re: Generic EPICS IOCs Pete Jemian 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 Anders Lindh Olsson via Tech-talk
- Next: Re: Generic EPICS IOCs Pete Jemian 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>
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·