Re: Modbus alarms question

[John Dobbins via Tech-talk <tech-talk at aps.anl.gov>]

Mark,

The sequence is now  TIMEOUT INVALID followed shortly thereafter  by COMM INVALID.

John

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Thursday, July 16, 2020 10:36 AM
To: John Dobbins <john.dobbins at cornell.edu>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: RE: Modbus alarms question

 

Ø  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

 

Mark,

 

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

 

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

 

 

John

 

 

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Thursday, July 16, 2020 9:19 AM
To: John Dobbins <john.dobbins at cornell.edu>
Subject: Re: Modbus alarms question

 

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