Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Wed, 4 Mar 2015 18:02:00 +0000

Hi Vishnu,

I have thought about this some more, and I think the problem is really in asyn device support and you should not change your driver to fix it.

I just did a test with the simDetector from areaDetector.  I opened the asynRecord.adl screen and disabled AutoConnect on that port (with the .AUCT field) and set the port to Disconnected (with the .CNCT field).  I then get a stream of error messages like you saw for records that are periodically processing:

2015/03/04 10:40:18.919 13SIM1:cam1:PoolUsedMem devAsynFloat64 queueRequest port SIM1 not connected
2015/03/04 10:40:18.919 13SIM1:cam1:PoolAllocBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 10:40:18.919 13SIM1:cam1:PoolFreeBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 10:40:19.119 13SIM1:cam1:PoolUsedMem devAsynFloat64 queueRequest port SIM1 not connected
2015/03/04 10:40:19.119 13SIM1:cam1:PoolAllocBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 10:40:19.119 13SIM1:cam1:PoolFreeBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 10:40:19.319 13SIM1:cam1:PoolUsedMem devAsynFloat64 queueRequest port SIM1 not connected
2015/03/04 10:40:19.319 13SIM1:cam1:PoolAllocBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 10:40:19.319 13SIM1:cam1:PoolFreeBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 10:40:19.519 13SIM1:cam1:PoolUsedMem devAsynFloat64 queueRequest port SIM1 not connected
...

This stream of messages will continue until the port connects.

This violates the "Dalesio" principle that there should be a single error message when the device becomes unavailable and a single message when it becomes available again.

I have just changed all of the asyn device support so that it only prints messages when the status returned from pasynManager->queueRequest changes.  This includes changes from asynSuccess to anything else, and from anything else to asynSuccess, so there is a message printed when the port reconnects.  This is the complete output now when I disconnect, wait a few seconds, and then reconnect the port:

2015/03/04 11:53:30.959 13SIM1:cam1:PoolUsedMem devAsynFloat64 queueRequest port SIM1 not connected
2015/03/04 11:53:30.959 13SIM1:cam1:PoolAllocBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 11:53:30.959 13SIM1:cam1:PoolFreeBuffers devAsynInt32 queueRequest port SIM1 not connected
2015/03/04 11:53:34.559 13SIM1:cam1:PoolUsedMem devAsynFloat64 queueRequest status returned to normal
2015/03/04 11:53:34.559 13SIM1:cam1:PoolAllocBuffers devAsynInt32 queueRequest status returned to normal
2015/03/04 11:53:34.559 13SIM1:cam1:PoolFreeBuffers devAsynInt32 queueRequest status returned to normal

This is much better.  There is one message for each record when the port disconnects, and another when it reconnects.  It does not quite meet the Dalesio principle because there is one message per record, not per port, but it is a lot better than an endless stream of messages.

I have committed these changes to the asyn Subversion repository (https://svn.aps.anl.gov/epics/asyn/trunk) so you can test the changes before the next official release of asyn.

Mark

________________________________
From: Mark Rivers
Sent: Wednesday, March 04, 2015 7:25 AM
To: Vishnu Patel
Cc: techtalk
Subject: RE: error on the IOC shell for asyn driver

When you called

pasynTrace->setTraceMask(pasynUser, 0)

had you connected that pasynUser to your driver with pasynManager->connectDevice()?  If so it should have stopped the messages.

I assume that you have set your driver to autoConnect.  So each time a record tries to process it will call your connect() routine.  You could put some logic there that senses if the port is disconnect and if there have been too many failed attempts and calls pasynTrace->setTraceMask(pasynUser, 0).  When there is a successful connection attempt you could call pasynTrace->setTraceMask(pasynUser, 1).

What is your driver talking to?  Is it using an underlying asyn driver, like drvAsynIPPort or drvAsynSerialPort?

Mark

________________________________
From: [email protected] [[email protected]]
Sent: Wednesday, March 04, 2015 2:30 AM
To: Mark Rivers
Cc: techtalk
Subject: Re: error on the IOC shell for asyn driver

Dear Mark,
   I tried to use

pasynTrace->setTraceMask(pasynUser, 0)

in the static asynStatus connect(void *pvt, asynUser *pasynUser) and in the In32 interface function.

but still the messages are continuously loaded on the IOC shell.

(1) where in the driver i have to use  pasynTrace->setTraceMask(pasynUser, 0)
 or asynSetTraceMask()
(2) and want to know is these message are displaying because of the port is not connected and record support is trying to access the port?

I checked that if i put asynSetTraceMask() after iocInit, it is stopping the displaying messages. But if i put before iocInit it is continuously displaying the messages.

So in my asyn based driver, where i should use this function so it execute after iocInit?

Thank you

Vishnu

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System