Re: [EXTERNAL] Suggestions wanted on IOC hardware

[Heinz Junkes via Tech-talk <tech-talk at aps.anl.gov>]

Hallo Greg,

Careful, I am also one of the old white grumpy men who still use VMEbus (with RTEMS).

For slow control I am using these kind of carrier (But we have so many of the boards in use that we also have spare parts):

https://www.acromag.com/shop/embedded-i-o-processing-solutions/carrier-boards-and-cards/vme-carrier-cards-carrier-boards-and-cards/avme9660a-vmebus-6u-carrier/

( https://www.msp.ch/embedded-computing/single-board-computers/vme-6u/vme-6u-m-module-carriers/products/i4000 )


And then you can use such IO modules for this:

https://www.artisantg.com/TestMeasurement/90703-1/Tews-Technologies-TIP501-10-16-Channel-Isolated-Multiplexed-16-Bit-A-D-IP-Module?srsltid�mBOorWm1Xmr0BxdilWVE8ouoPz08sFH6ewk6qrLYEyCP-xvzpOQwHM

TEWS in particular is still very active here with new product lines such as QMC.

https://www.tews.com/products/?_form_factor=qmc%2Cxmc&_discontinued�tive%2Cin-development%2Cnot-recommended-for-new-designs


However, when it comes to very few (or distributed) slow signals, we also use dedicated modules from ControlByWeb (https://controlbyweb.com/)
which we address via Modbus from the VM-IOC.

Viele Grüße
Heinz


> On 24. Jun 2025, at 20:53, Leblanc, Gregory via Tech-talk <tech-talk at aps.anl.gov> wrote:
>
> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature