Re: Suggestions wanted on IOC hardware

[Steven Hunt via Tech-talk <tech-talk at aps.anl.gov>]

I am hesitant to give any advice, as these issues get very religious, and people have strong opinions.   But anyway these are my thoughts after being in this business for a while: ...

Start with deciding  what feature you want,   do you want:

a) ALL status of all systems to be visible to EPICS or OK to 'hide' status in black-boxes such as PLCs or other subssytems?

b) Do you need good timestamping to be able to trigger measurements or correlate signals?   'old fashioned' systems using VME but also some new 'pizza box' systems can have timing system included.  We used to be able to trigger ADCs all across the facility  from the EPICS timing system to sub micro-second (or much  better) accuracy. The timestamp of the epics record can then be when the trigger happened, not when the record processes.

c) What resolution and accuracy of measurements do you need?  

d) Do you choose the same hardware for all systems, or do you 'save money' (it never does) by having both high speed systems and 'slow' controls.  Making all hardware and software the same  actually can save money in the long run - cost of hardware over the life of a facility is nothing compared with the cost of staff to build and maintain it.

e) Forty years ago the 'standard model' of control system had a middle layer with standard computers getting data from low level, often over a field-bus.  EPICS came along with a 'flat' model - only clients and servers, servers (iocs) can also be clients, data is visible is everywhere, and networking is fast. You could build a control system by configuring it, no programming necessary. The rest as they say is history :) ...  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.  

f) Networking ......   If I remember right the APS originally ran on a single 10Mbit (non switched) Ethernet. (Correct me if I am wrong). This was only possible by the amazing efficiency of channel access (Thanks Jeff).   Now we have gbit switched networks, which are great.  But we also tend to add non EPICS devices on the same networks, some broadcast sensitive. So we have subnets, virtual LANS, remote configuration to make maintenance faster (ha, ha, ha).  But with virtual LANS, subnets, routing, we get delays ( just try ping). And maintenance of these systems seems to take a large effort. IOCs used to run for years without rebooting, the network never changed, and required almost zero effort.  Adding features adds complexity, and usually does not reduce effort or increase reliability.

g) In the end what we need has not changed:   Read and write analogue and binary signals; Convert to engineering units; Check for Alarms; Calculate derived values  (soft records); Close loops; Provide info to operators (OPI); Trend Plots; Alarm display and Logs; Archive (we can now keep all data forever - important for machine learning).

h) How long should the system be operational for?  - five  years, ten years, thirty years - consider how much expertise you need in house (hardware and software) - will the tools you use be available over time.

 

OK, I sound like a grumpy old man (may be old but not grumpy) .  I am not saying build a system as it used to be, but do understand the pros and cons of what you put in.  :)

  

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