Experimental Physics and
Industrial Control System

Hi John,

 

I’ve done a little more investigating.  This statement from my previous message is incorrect.

 

Ø  The status returned for these 2 failure modes is different.  Failure mode 1) returns a “read” error, while failure mode 2) returns a “timeout” error.  For a particular record it can fail either way, and thus each record can be switching its alarm status.

 

It is actually the opposite, failure mode 1 returns a “timeout” error while failure mode 2 returns a “read” error.

 

The reason is that when asynManager::queueLockPort() times out it is returning the generic asynError code.  It would be more accurate for it to return asynTimeout.  This patch does that.

 

(sphinx) corvette:~/devel/asyn>git diff asyn/asynDriver/asynManager.c

diff --git a/asyn/asynDriver/asynManager.c b/asyn/asynDriver/asynManager.c

index deefbe7..2e10e6c 100644

--- a/asyn/asynDriver/asynManager.c

+++ b/asyn/asynDriver/asynManager.c

@@ -1840,7 +1840,7 @@ static asynStatus queueLockPort(asynUser *pasynUser)

                 "asynManager::queueLockPort queueRequest timed out");

             epicsMutexUnlock(plockPortPvt->queueLockPortMutex);

             pasynManager->freeAsynUser(pasynUserCopy);

-            return asynError;

+            return asynTimeout;

         }

         pasynManager->freeAsynUser(pasynUserCopy);

         asynPrint(pasynUser,ASYN_TRACE_FLOW, "%s asynManager::queueLockPort got event from callback\n", pport->portName);

 

If you apply that patch then I believe both failure modes will result in a “timeout” error and the alarm status should no longer toggle between READ and TIMEOUT.

 

I would be good if you could give that a try.  If it works I will commit that patch, since I think it is more logical.

 

Mark

 

 

 

Hi John,

 

I think I understand what is happening.  For “slow” devices (ASYN_CANBLOCK=1) asynManager queues a request for the I/O operation.  When the request gets to the head of the queue asynManager causes the actual I/O operation to be run in the port driver thread.

 

If the device is not available there are 2 ways a read operation can fail.

1)      The request gets to the head of the queue and the actual I/O operation times out. 

2)      The request spends too long in the queue, and the queue request itself times out.

 

The timeout for 1 is set in your startup script, in the modbusInterposeConfig command.  You set it to 2000 ms = 2.0 seconds.

The timeout for 2 is set by default in asynManager.c to 2.0 seconds as well.  It can be changed with the following iocsh command:

 

asynSetQueueLockPortTimeout(portName, timeout).

 

Failure mode 2 will happen when several requests are queued, and they each take timeout 1 to fail with failure mode 1.  Eventually some of the requests in the queue will exceed timeout 2, and they will fail with failure mode 2.

 

The status returned for these 2 failure modes is different.  Failure mode 1) returns a “read” error, while failure mode 2) returns a “timeout” error.  For a particular record it can fail either way, and thus each record can be switching its alarm status.

 

There are several ways this could be fixed.

 

1)      Change your startup script to have the read timeout be 200 ms rather than 2000.  That is probably plenty because the device should normally respond faster than that.  That would allow 10 requests to timeout before a queue request timeout occurred.  If that is not enough you could use the asynSetQueueLockPortTimeout to increase timeout 2, until all requests fail with mode 1.

 

2)      You could add the following command to your startup script:

asynSetOption(“MISC”, 0, “disconnectOnReadTimeout”, “Y)

That command causes asyn to disconnect the port if it times out.  That will put the port in the disconnected state.  If autoConnect is true then asynManager will keep trying to reconnect the device.  When it becomes available it will reconnect.

 

3)      I could change the Modbus driver so that if failure 1 is indeed a timeout (as opposed to some other error) it sets the alarm status to “timeout” rather than “read”.  Then both failure modes have the same alarm status.

 

I would suggest first trying method 2 and see what happens to the alarm status in that case.

 

If that does not work then try method 1.

 

If that does not work I will look at modifying the driver (method 3).

 

Mark