FW: AsynDriver with delayed and async communication

[Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>]

I forgot to CC tech-talk on this reply.

 

From: Mark Rivers
Sent: Wednesday, January 30, 2019 1:56 PM
To: 'Joao Afonso' <joao.afonso@cern.ch>
Subject: RE: AsynDriver with delayed and async communication

 

Hi Joao,

 

I would recommend writing a driver based on asynPortDriver. 

 

-          Its constructor will take the name of the drvAsynIPPort connected to your device.  It uses the asynOctetSyncIO interface to write and read from the device.  Look at asyn/testConnectApp for an example.

-          It will implement writeInt32, writeFloat64, or writeOctet methods that receive values for commands, format the command strings, and send them with pasynOctetSyncIO->write()

-          A separate thread created in the constructor will call pasynOctetSyncIO->read to periodically poll for responses.  It parses the responses and call setIntegerParam(), setDoubleParam(), or setStringParam() and then callParamCallbacks().  This will cause input records with SCAN=I/O Intr to be processed.

 

 

Ø   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.

 

I don’t know of any example where asynDriver is being used with TANGO yet, but it is interesting that you ask that question now.  I was recently at a beamline controls workshop in at BESSY-II in Berlin with both EPICS and TANGO developers.  I talked about areaDetector, which uses asyn.  Alain Buteau from Soleil asked if areaDetector drivers and plugins could be used with TANGO.  That has always been possible in my opinion, but when I got home I did some work on asyn to make it easier, and I sent a message to Alain about this.  He said his developers would investigate.

 

asyn has a class called asynPortClient.  It is connected to a specific asynPort and provides simple write() and read() methods to do synchronous I/O to the port driver.  It supports callbacks that will be called when any driver parameter changes.  Both the asynPort driver and the asynPortClient can be instantiated in a simple C++ program outside the context of an EPICS IOC.  I recently made this class simpler to use.

 

I have written a program in areaDetector/ADSimDetector/iocs/simDectectorNoIOC that tests and demonstrates this.  It instantiates an areaDetector simDetector, an NDPluginStats statistics plugin, and an NDFileHDF5 plugin.  It starts the detector, prints statistics values in callbacks, and saves HDF5 files.  This program was specifically written to demonstrate to TANGO developers that they can use areaDetector drivers without having to run an EPICS IOC or Channel Access.  It was recently made simpler and more powerful using the changes to asynPortClient.

 

If asyn is compiled with the flag EPICS_LIBCOM_ONLY then the only EPICS libraries that are required for a TANGO application are libCom (from base) and asyn.

 

Note that the improvements to asyn and ADSimDetector described above are in the master branch of these Github repositories, and are not yet officially released.  That will be done soon.

 

Mark

 

 

From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of Joao Afonso via Tech-talk
Sent: Wednesday, January 30, 2019 11:09 AM
To: tech-talk@aps.anl.gov
Subject: AsynDriver with delayed and async communication

 

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