|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||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|
|<== Date ==>||<== Thread ==>|
|Subject:||Re: AsynDriver with delayed and async communication|
|From:||"Johnson, Andrew N. via Tech-talk" <email@example.com>|
|To:||Joao Afonso <firstname.lastname@example.org>|
|Date:||Mon, 4 Feb 2019 20:05:20 +0000|
On 2/4/19 11:51 AM, Joao Afonso via Tech-talk wrote:
Not the way you have your database defined. You might be better off using a longout record though, so EPICS does the string to integer conversion and reports errors to the CA client automatically (or caput would tell you directly). Another advantage of a longout record is that you can set its DRVH and DRVL fields to clip the values can can be set to a specific numeric range.
No, and this is fairly fundamental to the design of EPICS and Channel Access; a get request should not affect the state of the IOC, so you can always query the state of your process database from outside without fear of changing it. This also encourages longer-lived clients to set up monitors instead of repeatedly polling for values, and prevents a control system from becoming reliant by accident on some external client that does periodic gets that trigger updates which other parts of the control system need to happen but aren't doing themselves.
Mark's earlier comment that he (as do many experienced EPICS users) prefers having a separate PV for set and get also relates to this. If there are other non-EPICS mechanisms by which the device parameters can be changed then you would probably want to process the GET records at some periodic scan rate so your users can see when those external changes have happened. By giving them a separate SET record they can see what value EPICS last set a parameter to, and can also set it back to that value very easily. If there's only one record for both SET and GET they get less visibility into what's going on, and have to type in a particular desired value again if it gets changed externally.
-- Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." -- Edward Snowdon