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: PV for both input AND output |
From: | Ralph Lange <[email protected]> |
To: | Matteo Pardi <[email protected]>, EPICS Tech-Talk <[email protected]> |
Date: | Fri, 17 Jan 2014 09:45:02 +0100 |
Hi Matteo,in addition to the solutions posted, that use two records to split the writing and reading operations, it is also feasible to completely manage things in the device support layer, while using one (output) record for both operations.
To achieve that, the device support keeps a flag in its per-record-instance structure to remember the type of the next operation. For a set point using an output record, the normal state of the flag would be "write". To work reliably, a write operation to the device must return the current value of that set point - either as an integral part of the protocol, or by the device support doing a read request immediately after writing the value.
When the device support receives a value from the device (either by polling or by an unsolicited message from the device), it caches the value, sets the flag of the affected record to "read", sets PACT and requests the record being processed through a callbackRequest function - initiating the second pass of an asynchronous processing.
The write() routine of the device support checks the per-record flag. If it is set to "write", it initiates a write request to the device, sets PACT, and returns. If it is set to "read", it reads the cached value from the device support, sends out monitors, resets PACT and the flag, and returns.
Race conditions appear if the IOC and another local master both write the value at (roughly) the same time. But these can not be avoided - no matter how hard you try to manage, if two masters write at the same time, only one will win. The important aspect: your device must forward all value changes in set points to the IOC, so that the record always shows the current value - no matter which master wins the race.
This method is being used by a couple of device supports dealing with "intelligent" devices with optional local control, namely PLCs through OPC or other protocols.
Cheers, ~Ralph