1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: device support for output connected to volatile device |
From: | John Dobbins <[email protected]> |
To: | Andrew Johnson <[email protected]>, EPICS Tech-Talk <[email protected]> |
Date: | Wed, 05 Dec 2007 10:39:51 -0500 |
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