Re: AsynDriver with delayed and async communication

["Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>]

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