1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: TCP connection status : drvAsynIPPort |
From: | Patel Jignesh <[email protected]> |
To: | Mark Rivers <[email protected]>, "[email protected]" <[email protected]> |
Date: | Wed, 8 Oct 2014 17:39:09 +0000 |
Hi Mark, Thanks for you reply and suggestions. What version of asyn are you using? ---I have tested the scenario on asyn version 4.21 and 4.23. Please turn on all asynTrace debugging on that port in your startup script: I think that failed write operations should trigger the channel to disconnect, but if not then we need to fix that. --- I have enabled asynTrace debugging and below are the observations…
-
The channel connection status is properly identified by either dummy read or write when we keep any length higher than 0.
-
In my case for write, I was trying dummy write with 0 length and it was not detecting the broken channel (I assumed that it will be supported as per the Release Notes : Release 4-5 “Serial, TCP/UDP/IP :---Handle 0-length write requests” ) I think write with 0 packet is valid situation in case of socket send
method..? --- asynTrace debugging messages in each scenario :
1.
Write with length 0 in case of PLC RUN/STOP mode (always return status : asynsuccess) 2014/10/08 08:57:29.025 10.130.1.168:2001 write. 2014/10/08 08:57:29.025 10.130.1.168:2001 write 0 2014/10/08 08:57:29.025 asynOctetSyncIO wrote: 2014/10/08 08:57:29.025 PLC_SAMPLE_CPU_2001 queueUnlockPort 2014/10/08 08:57:29.025 PLC_SAMPLE_CPU_2001 asynManager::queueUnlockPort waiting for event 2014/10/08 08:57:29.025 PLC_SAMPLE_CPU_2001 queueUnlockPort unlock mutex 0x7f3328000a40 complete.
2.
Write with length 1 in case of PLC RUN (in case of PLC STOP mode, I get asynerror and isConnected also detect the broken channel) 2014/10/08 09:14:30.231 10.130.1.168:2001 write. 2014/10/08 09:14:30.231 10.130.1.168:2001 write 1 \000 2014/10/08 09:14:30.231 wrote 1 to 10.130.1.168:2001, return asynSuccess. 2014/10/08 09:14:30.231 asynOctetSyncIO wrote: \000 2014/10/08 09:14:30.231 PLC_SAMPLE_CPU_2001 queueUnlockPort 2014/10/08 09:14:30.231 PLC_SAMPLE_CPU_2001 asynManager::queueUnlockPort waiting for event 2014/10/08 09:14:30.231 PLC_SAMPLE_CPU_2001 queueUnlockPort unlock mutex 0x7fbcf40009d0 complete. t2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort locking port 2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort taking mutex 0x7fbcf40009d0 2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort queueing request 2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 addr -1 queueRequest priority 0 not lockHolder 2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort waiting for event 2014/10/08 09:14:30.331 asynManager::portThread port=PLC_SAMPLE_CPU_2001 callback 2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback signaling begin event 2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort 2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort got event from callback 2014/10/08 09:14:30.331 10.130.1.168:2001 write. 2014/10/08 09:14:30.331 10.130.1.168:2001 write 1 But as this only unidirectional write channel so this dummy write will disturb the PLC performance as it will be considered as a valid data in case of write with higher than zero length not recommended as per the current implimenation. So below are the observations with READ
1.
Read with length 0 in case of PLC RUN/STOP mode (always return status : asynerror) 2014/10/08 09:38:14.406 10.130.1.168:2001 read. 2014/10/08 09:38:14.406 PLC_SAMPLE_CPU_2001 queueUnlockPort 2014/10/08 09:38:14.406 PLC_SAMPLE_CPU_2001 asynManager::queueUnlockPort waiting for event 2014/10/08 09:38:14.406 PLC_SAMPLE_CPU_2001 queueUnlockPort unlock mutex 0x7f100c000a00 complete. 2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort locking port 2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort taking mutex 0x7f100c000a00 2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort queueing request 2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 addr -1 queueRequest priority 0 not lockHolder 2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort waiting for event 2014/10/08 09:38:14.505 asynManager::portThread port=PLC_SAMPLE_CPU_2001 callback 2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback signaling begin event 2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort 2014/10/08 09:38:14.506 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort got event from callback 2014/10/08 09:38:14.506 10.130.1.168:2001 read.
2.
Read with length 1 in case of PLC RUN mode (normally return status : asyntimeout as PLC will not respond but in PLC STOP mode this return asynerror and isConnected also detect the broken channel ) Same as above Read with length 0
So I hope I am able to explain the scenario, one more thing this read and write with some dummy packet length are able to detect the broken connection if we keep PLC in STOP mode manually, but this method doesn’t detect the broken connection
if I disconnect the network cable from PLC after successful connection. Though in all cases, reconnection is established automatically by asyn. So do you recommend to use other low level socket options or please suggest the better method to detect the channel health. Thanks for your support. Best regards, Jignesh From: Mark Rivers [mailto:[email protected]]
Hi Jignesh, What version of asyn are you using? > So I have tried some active method to detect the connection status, like dummy write(as this is write channel) and after checking the connection status with icConnected() but that also don’t report the broken connection
Please turn on all asynTrace debugging on that port in your startup script: asynSetTraceIOMask(“myPort”,0,2) asynSetTraceMask(“myPort”,0,255) I think that failed write operations should trigger the channel to disconnect, but if not then we need to fix that. If you don’t attempt any write or read operations then isConnected() won’t detect a disconnect, because the driver only detects a disconnect when it tries to do a write or read. Mark From:
[email protected] [mailto:[email protected]]
On Behalf Of Patel Jignesh Hi, I am working on Siemens S7 PLC driver development based on Asyn. Currently I have two channels of communication between IOC application and PLC, one of which just sends data to PLC on specific port when there is change like simple commands
from user. So most of the time the channel remains ideal without any traffic. The other channel is bidirectional and have periodic data traffic on read direction. Now I want to monitor this channel connection status in case of disconnection or failure from PLC side. I tried with isConnected() function, which doesn’t not work with this channel. But this method is working for other channel where I
have bidirectional and periodic data traffic. So I have tried some active method to detect the connection status, like dummy write(as this is write channel) and after checking the connection status with icConnected() but that also don’t report the broken connection so finally I tried
with dummy read and checking the connection status with isConnected() which successfully detect the broken connection.. So please give comments for the above scenario and also suggest, is there any other method to check the connection status using drvAsynIPPort for such type of situation ? Thanks for your support, BR, Jignesh |