Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20192020  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  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: AsynDriver with delayed and async communication
From: "Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>
To: Joao Afonso <joao.afonso@cern.ch>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Mon, 4 Feb 2019 20:05:20 +0000
Hi Joao,

On 2/4/19 11:51 AM, Joao Afonso via Tech-talk wrote:
record(stringout, "INT32S:S")
{
   field(DTYP, "asynOctetWrite")
   field(OUT,  "@asyn($(PORT),0) TEST_INT32S_S")
   info(asyn:READBACK, "1")
}

If I monitor (camonitor) the record, and send a value (caput), the value I sent will be immediately displayed.
Then, a few moments later, when the response arrives, it will update accordingly:

INT32S:S                       2019-02-04 17:28:21.653208  
INT32S:S                       2019-02-04 17:28:40.056585 aaa                   ##value sent, which will be rejected by the device (is not an integer!)
INT32S:S                       2019-02-04 17:28:42.663142 18 bad integer ##response received from the device, with an error

This seems to be fine, for what I wanted!
Anyway, is there a way to avoid updating the record, before the readback is executed (in this case, the 'aaa' would not be displayed) ?
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.

For GET commands it got a bit more complicated...
At first, I tested it with an input record (stringin), with SCAN=Passive. And with this, I expected the record to be processed when I used caget.
However, I noticed that the 'readOctet' was never being run, so the value stayed the same. After reading the documentation, it seems to me that this is not possible unless I "trigger" the processing of the record (by running caput, or by linking to it from another record with PP).

Is there a way to  - always - trigger the processing of an input record when do a get, like using caget?
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.

HTH,

- Andrew
-- 
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

References:
AsynDriver with delayed and async communication Joao Afonso via Tech-talk
RE: AsynDriver with delayed and async communication Joao Afonso via Tech-talk
RE: AsynDriver with delayed and async communication Mark Rivers via Tech-talk
Re: AsynDriver with delayed and async communication Eric Norum via Tech-talk
RE: AsynDriver with delayed and async communication Mark Rivers via Tech-talk
RE: AsynDriver with delayed and async communication Joao Afonso via Tech-talk

Navigate by Date:
Prev: Re: Changing record fields while PACT=1 Johnson, Andrew N. via Tech-talk
Next: Re: Changing record fields while PACT=1 Klemen Vodopivec via Tech-talk
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  <20192020 
Navigate by Thread:
Prev: RE: AsynDriver with delayed and async communication Joao Afonso via Tech-talk
Next: RE: AsynDriver with delayed and async communication Mark Rivers via Tech-talk
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  <20192020 
ANJ, 04 Feb 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·