RE: [AsynDriver] getAddress and callbacks

[Joao Afonso via Tech-talk <tech-talk@aps.anl.gov>]

Hi Mark,

Sorry for the late response.

Thank you for implementing those changes.

For now, I had to modify the device support module in a way that is still compatible with previous versions of asynDriver, but I may go back to use "getAddress()" in the future.

Regarding the TIME fields, I think you are right. It was caused by an unrelated bug.

Best regards,

Joao

---

From: Mark Rivers [rivers@cars.uchicago.edu]
Sent: 19 June 2019 22:04
To: Joao Afonso
Cc: tech-talk@aps.anl.gov
Subject: RE: [AsynDriver] getAddress and callbacks

Ø  Do you foresee adding them in a future release?

 

I have changed the calls from pasynManager->getAddr() to asynPortDriver::getAddress() in all of the callback routines in asynPortDriver.  This will call your overridden getAddress() method, while having no impact on existing code that does not override this method.

 

Ø  The only problem I noticed is that the TIME field is now always showing <undefined>. I don't know if it was triggered by this, because I didn't look that much into it.

 

I did not observe that, the TIME fields of records which process as a result of asynPortDriver callbacks seem fine.  Perhaps you were looking at some records that had not yet processed?

 

My changes are on the master branch of asyn if you want to test them.

 

Mark

 

 

From: Joao Afonso <joao.afonso@cern.ch>
Sent: Monday, June 17, 2019 8:52 AM
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: tech-talk@aps.anl.gov
Subject: RE: [AsynDriver] getAddress and callbacks

 

Hi Mark,

 

Thank you for the clarification.

I was also wondering if those changes could be done.

 

I tried it like you suggested and it worked mostly fine.

The only problem I noticed is that the TIME field is now always showing <undefined>. I don't know if it was triggered by this, because I didn't look that much into it.

 

Anyway, I prefer not to have a dependency on a custom asynPortDriver modification, so I will try a different approach that doesn't depend on these changes.

 

Do you foresee adding them in a future release?

 

Best regards,

Joao

 

 

---

From: Mark Rivers [rivers@cars.uchicago.edu]
Sent: 14 June 2019 19:29
To: Joao Afonso
Cc: tech-talk@aps.anl.gov
Subject: RE: [AsynDriver] getAddress and callbacks

Hi Joao,

 

Perhaps I spoke too soon.  It seems like it might work to replace this in asynPortDriver.

 

        pasynManager->getAddr(pInterrupt->pasynUser, &address);

 

with this

 

        this->getAddress(pInterrupt->pasynUser, &address);

 

Why don’t you try that and see if it works?  If asynPortDriver::getAddress has not been overridden then this should not affect the existing behavior.

 

Mark

 

 

From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: Friday, June 14, 2019 12:23 PM
To: 'Joao Afonso' <joao.afonso@cern.ch>
Cc: tech-talk@aps.anl.gov
Subject: RE: [AsynDriver] getAddress and callbacks

 

Hi Joao,

 

Ø  In those cases, the IOC will get the address from "pasynManager->getAddr()", and not from getAddress(), which breaks the program.

Ø  (for ex. in paramList::octetCallback())

 

The callbacks are traversing a linked list of clients that have registered for callbacks.  This is typically asyn device support, but it is not limited to that.  That linked list is created outside of asynPortDriver by asynManager when each client registers for callbacks.   For example, this is the abbreviated code in devAsynInt32.c

 

    pasynUser = pasynManager->createAsynUser(processCallback, 0);

    pPvt->pasynUser = pasynUser;

    status = pasynEpicsUtils->parseLink(pasynUser, plink,

               &pPvt->portName, &pPvt->addr, &pPvt->userParam);

    status = pasynManager->connectDevice(pasynUser, pPvt->portName, pPvt->addr);

    status = pPvt->pint32->registerInterruptUser(

               pPvt->int32Pvt,pPvt->pasynUser,

               pPvt->interruptCallback,pPvt,&pPvt->registrarPvt);

 

So that pPvt->pasynUser has been connected to a particular port and address, typically specified in the OUT in INP link in the record.  The asynPortDriver callback functions are retrieving the address stored in that pasynUser in the linked list node via pasynManager->get_addr().

 

    pnode = (interruptNode *)ellFirst(pclientList);

    while (pnode) {

        asynInt32Interrupt *pInterrupt = (asynInt32Interrupt *) pnode->drvPvt;

        pasynManager->getAddr(pInterrupt->pasynUser, &address);

        /* If this is not a multi-device then address is -1, change to 0 */

        if (address == -1) address = 0;

        if ((command == pInterrupt->pasynUser->reason) &&

            (address == addr)) {

 

I don’t see how it could have access to the address that your getAddress() method is generating?

 

Mark

 

 

 

From: Joao Afonso <joao.afonso@cern.ch>
Sent: Friday, June 14, 2019 11:51 AM
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: tech-talk@aps.anl.gov
Subject: [AsynDriver] getAddress and callbacks

 

Hello Mark,

 

Sorry to bother you, I have a question regarding the usage of this function:

 

I have a use case where it is useful to override asynPortDriver::getAddress() to get a custom reason and address.

These values are chosen previously by drvUserCreate(), and stored in pasynUser->drvUser and pasynUser->reason.

 

This seems to work well for gets and puts, but not when a callback for for a "I/O Intr" record is executed.

 

In those cases, the IOC will get the address from "pasynManager->getAddr()", and not from getAddress(), which breaks the program.

(for ex. in paramList::octetCallback())

 

Is there a way to make the callbacks also use the custom asynPortDriver::getAddress() value?

 

Thank you in advance,

Joao