RE: Fast, reliable remote I/O in 2015

[Mark Rivers <rivers@cars.uchicago.edu>]

Hi Andrew,

 

With PLCs there are two timescales you need to consider.  The first is how quickly the PLC itself can react to the signal, using ladder logic for example.  The second is how quickly the change of an input is communicated to EPICS.  With the PLCs I have worked with (Allen Bradley SLC-500 and all Modbus PLCS using my EPICS software) the communication with EPICS is done via polling over some communication channel.  With the Koyo Modbus PLCs I typically poll at 10 Hz, so the average latency in detecting a transition will be 50 ms and worst-case would be 100 ms.  I’m sure it could be polled faster, but I have not tested how fast the PLC can respond.  There may be PLCs that can send data automatically to EPICS on a change of input state, but I am not aware of them.

 

Another option are the USB devices from Measurement Computing.  I have support for a number of these here, and all support at least 8 digital I/O bits.

 

http://cars.uchicago.edu/software/epics/measComp.html

 

I just did a quick test with the USB-CTR08, which can be used as an EPICS scaler and multi-channel scaler, but also supports 8 digital I/O signals.  It only costs $429.

 

http://www.mccdaq.com/usb-data-acquisition/USB-CTR08.aspx

 

I connected a binary output to a binary input and then ran camonitor to see how quickly the input changed state when I changed the state of the output via a Channel Access put.  I measured this with the camonitor program running on the same computer that is controlling the hardware.  Here are the results.  I’ve added annotation after each change that gives the latency.

 

J:\epics\devel\measComp>camonitor -tc USBCTR:Bo1 USBCTR:Bi3

USBCTR:Bo1                     (2015-08-19 17:03:43.873133) High

USBCTR:Bi3                     (2015-08-19 17:03:43.877075) High (4 ms)

USBCTR:Bo1                     (2015-08-19 17:03:44.505137) Low

USBCTR:Bi3                     (2015-08-19 17:03:44.507717) Low  (2 ms)

USBCTR:Bo1                     (2015-08-19 17:03:45.048369) High

USBCTR:Bi3                     (2015-08-19 17:03:45.055462) High (7 ms)

USBCTR:Bo1                     (2015-08-19 17:03:45.647819) Low

USBCTR:Bi3                     (2015-08-19 17:03:45.650384) Low  (3 ms)

USBCTR:Bo1                     (2015-08-19 17:03:46.167485) High

USBCTR:Bi3                     (2015-08-19 17:03:46.176412) High (9 ms)

USBCTR:Bo1                     (2015-08-19 17:03:46.718940) Low

USBCTR:Bi3                     (2015-08-19 17:03:46.726020) Low  (8 ms)

USBCTR:Bo1                     (2015-08-19 17:03:47.238455) High

USBCTR:Bi3                     (2015-08-19 17:03:47.242538) High (4 ms)

USBCTR:Bo1                     (2015-08-19 17:03:47.901714) Low

USBCTR:Bi3                     (2015-08-19 17:03:47.904288) Low  (3 ms)

USBCTR:Bo1                     (2015-08-19 17:03:48.453459) High

USBCTR:Bi3                     (2015-08-19 17:03:48.456179) High (3 ms)

USBCTR:Bo1                     (2015-08-19 17:03:49.044768) Low

USBCTR:Bi3                     (2015-08-19 17:03:49.047978) Low  (3 ms)

USBCTR:Bo1                     (2015-08-19 17:03:49.485097) High

USBCTR:Bi3                     (2015-08-19 17:03:49.488430) High (3 ms)

USBCTR:Bo1                     (2015-08-19 17:03:50.061665) Low

USBCTR:Bi3                     (2015-08-19 17:03:50.064231) Low  (3 ms)

USBCTR:Bo1                     (2015-08-19 17:03:50.558172) High

USBCTR:Bi3                     (2015-08-19 17:03:50.560882) High (2 ms)

USBCTR:Bo1                     (2015-08-19 17:03:51.022645) Low

USBCTR:Bi3                     (2015-08-19 17:03:51.025241) Low  (3 ms)

 

The latency is determined by the polling period, which was 0.01 seconds.  That should have led to a 5 ms average latency and 10 ms worst case.  That corresponds roughly to what I measured.  In this configuration the IOC was using less than 1% of the CPU time on the system.

 

I am sure that the system can poll faster without consuming too many resources.  Unfortunately Windows has a minimum time for epicsThreadSleep of 0.01 seconds, so it cannot poll any faster on Windows without coming up with some other delay mechanism.  There are Linux drivers available for some Measurement Computing devices, but no EPICS support for those drivers since they use different libraries.

 

Measurement Computing also offers a new high-speed 32-bit Digital I/O module for $499:

 

http://www.mccdaq.com/usb-data-acquisition/USB-DIO32HS.aspx

 

This device can stream the input values at up to 8 million samples/sec, so it has much faster response.  You would need to modify the driver to handle this data, but I already have drivers that handle streaming analog data.

 

Mark

 

 

 

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Gomella, Andrew (NIH/NHLBI) [F]
Sent: Wednesday, August 19, 2015 4:06 PM
To: tech-talk@aps.anl.gov
Subject: Fast, reliable remote I/O in 2015

 

Hi Everyone,

 

We are in need of some simple, yet fast remote I/O solutions in our lab. Namely we are looking digital inputs and outputs accessible as EPICS PVs for various fast synchronization tasks. 

 

Our current solution has been to use National Instruments DAQ boards which has been relatively unreliable (if the computer shuts off, so does the DAQ; No EPICS support that I know of from any facility; Only well supported by NI with Windows use, their Linux drivers do not work for us) They seem much more suited to isolated measurement tasks, rather than as "always on" hardware controllers.

 

I imagine most people in the EPICS world would use PLC's for this, as I found in a Tech-Talk thread on essentially the same topic in 2009 : http://www.aps.anl.gov/epics/tech-talk/2009/msg01775.php or use VME crates (it seems there is a gradual trend away from using VME for simple I/O tasks) 

 

We are looking for a simple, reliable solution that in the end results in simply having one record per digital in, one record per digital out. Ideally it would be very fast so we could act quickly on callbacks to input value changes ( <1ms would be ideal but 5ms is acceptable). 

We would likely have must of our logic running elsewhere in Python, so we do not necessarily need ladder logic or other embedded software to execute logical tasks (besides maybe what action to take if a watchdog timer fails). 

 

After searching tech-talk I compiled this short list of options, though I am curious if anyone else has better ideas for this specific application since 6 years has passed since some of these threads:

 

Koyo PLC's with softIOC using the modbus EPICS module

-Mark River's notes here that this allows direct access to memory registers so it can be used as a "simple I/O system" http://www.aps.anl.gov/epics/tech-talk/2009/msg01797.php

 

Yokogawa PLCs with embedded Linux

- as demonstrated by KEK here: http://www-linac.kek.jp/cont/epics/f3rp61/ and discussed here:  http://www.aps.anl.gov/epics/tech-talk/2009/msg01795.php

-Having embedded EPICS on a PLC seems like a very attractive idea. 

 

WAGO or Beckhoff PLCs using EtherCAT as recently described here

-http://www.aps.anl.gov/epics/tech-talk/2014/msg01315.php

 

(Epics Brick seemed like a great idea when I first read about it then realized it was discontinued in 2008) 

 

I have to note that it seems many PLCs digital inputs are not as fast as we would like (the entire Koyo Click series seems to only guarantee a max response of 10ms for off to on and on to off so that removes this option for us). 

 

I'm sure a lot has changed in the past 6 years, and that I missed some options so any advice would be greatly appreciated. 

 

Thanks in advance,

 

Andrew Gomella

 

Imaging Physics Lab, NHLBI, NIH