Re: device support for output connected to volatile device

[Andrew Johnson <anj@aps.anl.gov>]

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
--
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right.  When he states that something
is impossible, he is very probably wrong.  -- Arthur C. Clarke