Re: [EXTERNAL] Re: Suggestions wanted on IOC hardware

["Hill, Jeff via Tech-talk" <tech-talk at aps.anl.gov>]

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Steven Hunt via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, May 30, 2025 12:21 PM
To: James P. Withrow <jwithrow at cornell.edu>
Cc: Tech-talk at aps.anl.gov <Tech-talk at aps.anl.gov>
Subject: [EXTERNAL] Re: Suggestions wanted on IOC hardware

 

>> 'old fashioned' systems using VME

For slow controls,  vendor agnostic back-plane modular systems such as VME are certainly more expensive, but for DSP based timed data acquisition a  modern equivalent system such as VPX may still  remain to be relevant!

If the system should be installed over a long time period then vendor neutrality and modular components become bigger considerations, but yes for slow controls Ethernet can be our vendor neutral modular integration interface.

>> except we seem to be moving back to this old model, IOCs no longer have direct hardware interface, but run on unix systems and talk to the low level I/O systems which can be PLCs, simple embedded systems not running EPICS, or instruments.

Yes, for slow controls, but for timed scalar, waveform, and image data  acquisition perhaps the the low latency flat model remains valid.

Control room operators conntinue to identify the flat model as being miuch simpler to fault isolate. They like to identify what IOC the EPICS PV is on and restart it. Yes, they shouldnt need to do that, but in the middle of the night its expedient.

>> OK, I sound like a grumpy old man (may be old but not grumpy) .  

Get in line!

  

On Wed, May 21, 2025 at 6:02 AM James P. Withrow via Tech-talk <tech-talk at aps.anl.gov> wrote:

Hello all-

I'm investigating the eventual migration of our control system to EPICS, and as such, I would like to solicit community input on IOC hardware which I can use as a 'boilerplate' configuration for common tasks like sensor (I2C/SPI) polling, instrumentation (RS232/485), and general IO.

• Ideally runs RTEMS and EPICS easily, with Linux and EPICS as a second choice.
• Supports GPIO and standard peripheral interfaces such as SPI, I2C, and UART.
• Can be initially set up with a standard configuration but be customized as needed.
• Has reliable persistent storage for operating system and configuration data.
• Is slightly more powerful than we think we need at the moment to allow for future-proofing.

Current searching has turned up mostly references to Beaglebone and Zynq hardware, however I'd like to hear from community members as to what's in use 'in the wild' and how well it works - or doesn't - for your applications.

Thanks!

-Jim Withrow