Experimental Physics and
Industrial Control System

On Feb 24, 2022, at 7:46 AM, Mark Rivers <rivers at cars.uchicago.edu> wrote:

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