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
Jignesh PATEL
Control Systems Integration Technician
CODAC Section
ITER Organization, Building 72/286, CHD, Control System Division
Route de Vinon-sur-Verdon - CS 90 046 - 13067 St Paul Lez Durance Cedex – France
Phone: +33 4 42 17 84 72
Get the latest ITER news on
http://www.iter.org/whatsnew
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
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
Jignesh PATEL
Control Systems Integration Technician
CODAC Section
ITER Organization, Building 72/286, CHD, Control System Division
Route de Vinon-sur-Verdon - CS 90 046 - 13067 St Paul Lez Durance Cedex – France
Phone: +33 4 42 17 84 72
Get the latest ITER news on
http://www.iter.org/whatsnew