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: AsynDriver with delayed and async communication
From: Joao Afonso via Tech-talk <tech-talk@aps.anl.gov>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 30 Jan 2019 17:09:16 +0000
Hello again,

I am now designing a driver to communicate with a device using arrays of characters, via TCP.
Conceptually it is simple: for each command sent to the device there is always a response, but they can arrive out of order.

Example:

Commands sent:
"$<tag_1> <cmd_1>"
"$<tag_2> <cmd_2>"

Responses received (out of order):
"$<tag_2> <rsp_2>"
"$<tag_1> <rsp_1>"

Some commands may take much longer time to be served, so this allows all responses to be returned as soon as they are ready.


Considering this, I would like to create an IOC where each record corresponds to a different command (these commands are actually a set/get of a property value, but I think that it is not relevant for the question).
These records would be SCAN Passive, and every read/write would force the value to be processed (i.e. read/written directly from/to the device, not cached in the records).


What would be the best approach for this?

We though of two options:

1) Use StreamDevice:
 - Is quite easy to implement and we know it can work.
 - However, the every time a record is being processed, it will lock the port while waiting for the respective response. This will block other users and can result in poor performance.
 - Also, I don't think it supports tags.

2) Use asynDriver:
 - From what I understood, it is possible to stop a callback and send it back to the queue using the 'callbackRequestDelayed()' EPICS function. This, with the help of a state machine, would allow the callback to be executed in two steps, and not block callbacks from other users. It seems to be similar to the approach taken on the asynDriver '<top>/testApp'.
 - In this case, a separate thread would receive all the results, and store them in a place where the callbacks would read later.
 - However, I don't know if it is fully compatible with asynDriver, or if asynDriver provides a better mechanism for this type of interaction. Is there a better approach?


Maybe there is a 3rd better option that I am not aware of, and that is why I am asking this question. For now, if it works, the #2 seem to be the better one.


I also have another unrelated question: is there any situation where asynDriver has been used with TANGO?
I have seen it mentioned on documentation, but I haven't found any example where a TANGO infrastructure if able to interact with a device through asynDriver.
For now, I am developing for EPICS, but if this could be ported to TANGO somehow, it would be very helpful.


Thank you in advance,
Joao Afonso
CERN TE-EPC-CCS


Replies:
Re: AsynDriver with delayed and async communication Eric Norum via Tech-talk

Navigate by Date:
Prev: Re: EPICS CSS with OPC UA Abhijit Bhopale via Tech-talk
Next: Re: AsynDriver with delayed and async communication Eric Norum 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: EPICS CSS with OPC UA Abhijit Bhopale via Tech-talk
Next: Re: AsynDriver with delayed and async communication Eric Norum 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, 30 Jan 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·