EPICS Controls 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  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  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: AsynDriver with delayed and async communication
From: Mark Rivers via Tech-talk <[email protected]>
To: 'Eric Norum' <[email protected]>
Cc: Joao Afonso <[email protected]>, "[email protected]" <[email protected]>
Date: Thu, 31 Jan 2019 22:18:27 +0000

>> You really don’t need the SET response record because that information be set in the STAT and SEVR of the SET record.

Ø  Perhaps, but I don’t see how the SET command would get its response — the network input port/stream is tied up by the read thread, right?  Or do SET and GET commands use separate ports?  Also, if SET commands can be ’slow’ then their responses woud be better handled by a read thread.

 

My mistake, I forgot that the SET message takes a long time to reply so its response also needs to be handled by the read thread.

 

The output record can get its STAT and SEVR updated from the polling thread, but only if it has the asyn:READBACK info tag.  See the asyn/testErrorsApp for an example.  So a single record can still work to hold the Set value, Set status, Get value, and Get status.  If the Set and the Get generate different errors the STAT will toggle between them.

 

Mark

 

 

 

From: Eric Norum <[email protected]>
Sent: Thursday, January 31, 2019 12:22 PM
To: Mark Rivers <[email protected]>
Cc: Joao Afonso <[email protected]>; [email protected]
Subject: Re: AsynDriver with delayed and async communication

 

On Jan 31, 2019, at 10:08 AM, Mark Rivers via Tech-talk <[email protected]> wrote:

 

Hi Joao,

 

Ø  Then, if am correct, this means I will require 2 records for each command, right?

Ø  One (for ex. stringout) to send the command and other (ex. stringin) to capture the responses with I/O Intr.

 

In my drivers I generally use 2 records, one for the Set (ao, longout, stringout, mbbo, etc.) and one for the Get (ai, longin, stringin, mbbi, etc.).

 

If you write an asynPortDriver then your records would normally not be stringout and stringin, they would be the records hold the underlying data type of the property (ao/ai, bo/bi, mbbo/mbbi, stringout/stringin only for string parameters).  The driver formats these into strings for Sets and parses the response for Gets.

 

It is possible to use a just an output record if the record has the info tag asyn:READBACK=1.  Then the output record value is updated with a Get operation.  I think it’s generally better to use 2 records since you then have independent error status of the Set and Put operations.  You can also see on the OPI display if the Get value does not match the Set value, because of things like out-of-bounds, truncation/rounding, etc.

 

If the second option is also not possible, then 4 records may be necessary for each property:

- For SET command

- For SET response with IO Intr

- For GET command

- For GET response with IO Intr

 

You really don’t need the SET response record because that information be set in the STAT and SEVR of the SET record.

Perhaps, but I don’t see how the SET command would get its response — the network input port/stream is tied up by the read thread, right?  Or do SET and GET commands use separate ports?  Also, if SET commands can be ’slow’ then their responses woud be better handled by a read thread.

 

You don’t need the GET command record, that string is constructed in the driver.

I’ve found it useful to have a ’trigger readback’ record.  That makes it easy to control the rate at which readbacks are requested.

 

So my $0.02 is that it’s best to have four records.  Although perhaps s single ’trigger readback’ record could be used to request a number of responses.

-- 
Eric Norum
[email protected]



 


Replies:
RE: AsynDriver with delayed and async communication Joao Afonso via Tech-talk
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

Navigate by Date:
Prev: Re: AsynDriver with delayed and async communication Eric Norum via Tech-talk
Next: Alarm Table Widget for BOY Vishnu Patel 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  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: AsynDriver with delayed and async communication Eric Norum via Tech-talk
Next: RE: AsynDriver with delayed and async communication Joao Afonso 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  2021  2022  2023  2024 
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 ·