Experimental Physics and
Industrial Control System

John Dobbins <[email protected]> · Wed, 05 Dec 2007 10:39:51 -0500

First thanks to the responders. In addition to Andrew, Emmanuel Mayssat, Mark
Rivers, Erik Johansson.
I agree this is not an ideal situation, having multiple paths to control
hardware with one of those paths being outside EPICS. However I find when I
purchase network capable hardware it generally comes with a vendor supplied
interface which turns out to be useful at one point or another. Given this
situation I want to be sure that the operator screens reflect the current state
of the hardware.
I considered the solution of having a readback record for each output. In my
case there are many outputs and this would have led to even more cluttered
displays. My device support is in fact scanning, the state of all registers is
readback periodically, so it was fairly straight forward to modify it in the
style of the Ether_IP device support (thanks Kay for the example).
John Dobbins

Andrew Johnson wrote:

John Dobbins wrote:

I am working on device support for a device which is volatile in the
sense that it can change in ways other than through the EPICS IOC. For
inputs this is not a problem, periodically scanned input records will
get the current value. For output records it is not obvious how to
deal with this. I would like the output values displayed on the
operator screen to be correct even when they are changed via means
external to EPICS.

The EPICS record types weren't really written with this in mind. The
usual approach to solving this is for every output record to have a
separate input record that reflects the actual setting read back from
the device; the user can see that their last request value is different
to the current setting and infer that the output was changed via the
other control method.
Ether_IP, the device support for Allen-Bradley hardware, is an example
of a device support that does this. The device driver periodically
reads from hardware the values corresponding to EPICS output records
and executes a callback to update the output record. In this way the
EPICS output record has the correct value even if someone changes a
PLC tag via the vendor software RSLogix.
Is there another example of a device support which does this?

Something in my subconscious is telling me that this can lead to
incorrect values being displayed if changes are made from both sources
simultaneously. If I set the record at the same moment that it's being
changed by some other controller, my change results in a message getting
queued from the record to the device, but if it queues up a message to
me at the same time saying that the value was changed from outside, its
message will override my value in the record but my message will still
change the actual output value. When that happens, my display of the
record value shows that my put failed when actually it succeeded.
I guess this problem only occurs if the protocol is message-based and
not scanned; for a protocol like EtherIP where the driver is continually
scanning the PLC, the next scan would clear up the problem and show the
actual state of the output. Thus if you're using a message-based
protocol the above two-record approach is safest, but if you're going to
be continually scanning the device Kay's method should be safe.
HTH,
- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System