Ø
I would suggest now adding this to your startup script after creating the MISC port.
asynSetOption(“MISC”, 0, “disconnectOnReadTimeout”, “Y)
> That's better. Thanks.
initial state:
MSD_S1F_FLD_CR 2020-07-16 09:36:52.285315 STATE MAJOR
I unplug the cable:
MSD_S1F_FLD_CR 2020-07-16 09:37:25.876095 TIMEOUT INVALID
MSD_S1F_FLD_CR 2020-07-16 09:37:26.376358 READ INVALID
OK, good. There is still something I am not completely happy with. Note that first you get a TIMEOUT alarm, which is correct. But once the port disconnects you get a READ alarm which is not really correct.
The asynStatus should be asynDisconnected which maps to COMM alarm. That would be more meaningful. I think this patch will fix the problem.
(sphinx) corvette:asyn/asyn/asynDriver>git diff .
diff --git a/asyn/asynDriver/asynManager.c b/asyn/asynDriver/asynManager.c
index deefbe7..911e14e 100644
--- a/asyn/asynDriver/asynManager.c
+++ b/asyn/asynDriver/asynManager.c
@@ -1829,7 +1829,7 @@ static asynStatus queueLockPort(asynUser *pasynUser)
pasynUserCopy->errorMessage);
epicsMutexUnlock(plockPortPvt->queueLockPortMutex);
pasynManager->freeAsynUser(pasynUserCopy);
- return asynError;
+ return status;
}
/* Wait for event from the port thread in the queueLockPortCallback function */
asynPrint(pasynUser,ASYN_TRACE_FLOW, "%s asynManager::queueLockPort waiting for event\n", pport->portName);
@@ -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);
You have already applied the second change in this patch. Could you also try the first change and see if that changes the final alarm to COMM alarm?
Thanks,
Mark
From: John Dobbins <john.dobbins at cornell.edu>
Sent: Thursday, July 16, 2020 8:46 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Subject: Re: Modbus alarms question
MSD_S1F_FLD_CR 2020-07-16 09:36:52.285315 STATE MAJOR
I unplug the cable:
MSD_S1F_FLD_CR 2020-07-16 09:37:25.876095 TIMEOUT INVALID
MSD_S1F_FLD_CR 2020-07-16 09:37:26.376358 READ INVALID
2+ minutes late I plug the cable back in and it recovers promptly
MSD_S1F_FLD_CR 2020-07-16 09:40:02.911512 STATE MAJOR
I think you are seeing is due to Linux taking a really long time to realize that the device is disconnected and closing the socket. I think that eventually it would reconnect, but it can take hours. Windows
is better with this.
I would suggest now adding this to your startup script after creating the MISC port.
asynSetOption(“MISC”, 0, “disconnectOnReadTimeout”, “Y)
I am very interested to know what you see when you do that.
Mark
________________________________
From: John Dobbins <john.dobbins at cornell.edu>
Sent: Thursday, July 16, 2020 8:10 AM
To: Mark Rivers
Subject: Re: Modbus alarms question
Mark,
That fixed my problem. Thanks!
My test involves disconnecting the network cable from the PC hosting the simulated PLC. When I unplug the cable I now get a single transition to "TIMEOUT INVALID". When I plug the cable back in things return to normal.
In doing this testing I did notice something else I wanted to ask about. If the time the cable is unplugged is > ~ 2 minutes, the connection between the IOC and the simulated PLC is not restored when I plug the cable back in (though it is for shorter outages).
The record remains in the "TIMEOUT INVALID" state. Is this what you would expect?
John