Experimental Physics and
Industrial Control System

Hi Eric,

 

I am bringing this thread back to tech-talk, because I believe I understand the problem.

 

Ø  The only difference in the initAi and initLi in devAsynInt32.c is that initAi calls ‘converrtAi’

 

That is not true, initAi calls getBounds(), but initLi does not.

 

    /* Don't call getBounds if we already have non-zero values from

     * parseLinkMask */

    if ((pPvt->deviceLow == 0) && (pPvt->deviceHigh == 0)) {

        pasynInt32SyncIO->getBounds(pPvt->pasynUserSync,

                                    &pPvt->deviceLow, &pPvt->deviceHigh);

    }

 

That is the solution to the mystery. 

 

The problem is that asynManager assumes that connections are always made by an asyn client (e.g. device support), either by pasynManager->queueRequest to a port with autoConnect=true or directly with a call to pasynCommon->connect().  However, as you have found there can be cases where this does not happen, because device support never actually calls the driver.  The record communicates with the driver only via driver callbacks, i.e. the driver calls the client function, not the other way around.  asynManager should be fixed so that if there is a driver callback on a specific port and address it marks that device as connected.

 

This issue will typically only show up for drivers with asynMultidevice=true.  The reason is that if multiDevice is false then all operations to the driver  are on address 0, and there is typically at least one record that talks directly to the driver, i.e. is not SCAN=I/O Intr.  So address 0 will show as connected.

 

Mark