RE: AsynDriver with delayed and async communication

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

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.

 

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

 

Mark

 

 

From: Joao Afonso <joao.afonso@cern.ch>
Sent: Thursday, January 31, 2019 11:45 AM
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: wenorum@lbl.gov; tech-talk@aps.anl.gov
Subject: RE: AsynDriver with delayed and async communication

 

Thank you Mark and Eric,

 

I think I understood your suggestion, from the point of view of the asynPortDriver.

 

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.

Or could I just expose it to the clients as a single record?

 

 

 

To give a bit more context about our protocol, all of our commands correspond to getting/setting of a property value (out of many properties):

 

In both sets and gets, I always receive a formatted string with the response:

- In case of a SET, the response will just tell if the set was successful and, if not, return the error code.

- In case of a GET, the response will return a value or, if it failed, the error code.

 

 

Ideally, I would like to have a match one-to-one between each property and one EPICS record.

This would mean that when I write a value to record, it would be interpreted as a SET command by the asynDriver, and when I read it would be interpreted as a GET command.

Is this something possible to implement, alongside with what you explained on the previous email?

I am aware that it is possible to create very complex systems using just records, but I just know the basics.

 

If this is not possible, I thought of using two records for each property: one for the SET, the other for the GET.

But this would still require interacting with both the command and the response a single record.

 

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

 

In your experience, what is the best approach?

 

 

About the usage of asynDriver with TANGO, it is interesting that the topic has been brought up recently.

We haven't yet decided on how we are going to create the interface for TANGO, but I will definitely take a look on how the 'simDectectorNoIOC' program works.

 

Thanks,

Joao Afonso

 

 

 

 

 

 

 

 

 

---

From: Mark Rivers [rivers@cars.uchicago.edu]
Sent: 30 January 2019 20:56
To: Joao Afonso
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