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

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

Is there any hardware available that supports this approach?  The only things that I’m aware of are VME-based high-speed, high-resolution digitizers.  These don’t seem suitable for data as slow as 10Hz.  Currently our fastest controls data is only being gathered at 1Hz, and our standard interval is 1 or 2 samples per minute. 

 

Our neutron and gamma ray detectors often utilize VME or dedicated ADC hardware, but they also use custom software for near real-time visualization.  I don’t know that EPICS would make sense there, as I feel that it requires substantial background knowledge and effort to implement.

    Greg

 

--

Gregory Leblanc

Accelerator Engineer

Edwards Accelerator Lab - Ohio University

123 University Terrace

Athens, OH 45701 USA

leblanc at ohio.edu

M: (401) 52-OUAL1 or (401) 526-8251

https://orcid.org/0000-0001-7899-5296

 

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Steven Hunt via Tech-talk
Sent: Tuesday, June 3, 2025 12:33 PM
To: Hill, Jeff <johill at lanl.gov>
Cc: Tech-talk at aps.anl.gov
Subject: Re: [EXTERNAL] Re: Suggestions wanted on IOC hardware

 

I was trying to be neutral, but if I was building a new system today, especially if timing and longevity  was important   ..... I would still go with the 'old fashioned'  flat architecture, and open backplane for all signals, fast and slow.  

 

Remember, people (effort) costs more than hardware

 

But that is me. 

 

On Tue, Jun 3, 2025 at 9:17 AM Hill, Jeff <johill at lanl.gov> wrote:

 

 

---

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