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: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>, Pete Jemian <jemian at anl.gov> |
| Date: | Tue, 16 Jan 2024 15:46:03 +0000 |
At
GSECARS (APS sector 13) we have used a single IOC image since day one of EPICS use. This image is used for all IOCs except areaDetectors and a few other detectors, e.g. Xspress3. That image is built for multiple architectures (linux-x86_64, linux-x86_64-centos6,
windows-x64-static, windows-x64, vxWorks-ppc32, etc.) That IOC supports all devices we use anywhere on the beamlines except areaDetectors, and many that we don't currently use but might in the future. For areaDetector we use the IOC images that are built
in areaDetector itself. The areaDetector iocBoot directories are custom and in a location outside of areaDetector.
Mark
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Pete Jemian via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, January 16, 2024 9:15 AM To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov> Subject: Re: Generic EPICS IOCs 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. ----------------------------------------------------------- |
- 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
- Re: Generic EPICS IOCs Ralph Lange via Tech-talk
- Re: Generic EPICS IOCs Pete Jemian via Tech-talk
- Navigate by Date:
- Prev: Re: ADVimba CPU usage Mark Rivers via Tech-talk
- Next: Re: drv_libera_env.c file of Libera Single Pass Johnson, Andrew N. 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 Pete Jemian via Tech-talk
- Next: Re: Generic EPICS IOCs Andrea michelotti 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 ·