Experimental Physics and
Industrial Control System

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