search

Beckhoff / ADS

Beckhoff protocol to communicate with TwinCAT devices.
MIT License
502 stars 194 forks source link

Got connection closed when using AdsSyncAddDeviceNotificationReqEx #85

Closed bogdanul2003 closed 5 years ago

bogdanul2003 commented 5 years ago

Hello,

I'm running the example application but instead of reading the byte array from the PLC, I'm reading a boolean. This is the ouput I get: `./example.bin 2019-04-24T11:32:13+0200 Info: Connected to 192.168.3.245 notificationByNameExample(): Hit ENTER to stop by name notifications NetId: 192.168.3.245.1.1 hUser 0x0 sample time: 132005755629710000 sample size: 1 value: 0x1

NetId: 192.168.3.245.1.1 hUser 0x0 sample time: 132005755639710000 sample size: 1 value: 0x1

NetId: 192.168.3.245.1.1 hUser 0x0 sample time: 132005755649710000 sample size: 1 value: 0x1

NetId: 192.168.3.245.1.1 hUser 0x0 sample time: 132005755659710000 sample size: 1 value: 0x1

NetId: 192.168.3.245.1.1 hUser 0x0 sample time: 132005755669710000 sample size: 1 value: 0x1

NetId: 192.168.3.245.1.1 hUser 0x0 sample time: 132005755679710000 sample size: 1 value: 0x1

2019-04-24T11:32:19+0200 Info: connection closed by remote`

The CycleTime is 1 second and some times I get more callbacks called sometimes I get less. Is there a way to find out the reason why the connection was dropped (it seems I receive 0 bytes at some point and there is no other error)?

pbruenn commented 5 years ago

Don't expect your callback to be executed in hard real time manner. Your ADS connection is a simple TCP stream, so your callback won't be called exactly each 1000ms even on a real time kernel.

Reading 0 byte makes sense, when looking at: https://github.com/Beckhoff/ADS/blob/eda55603f88bcbebd397060a02b12377debd2137/AdsLib/Sockets.cpp#L116-L119

You could put a breakpoint there or improve the error message, for more detailed analysis. I am not sure what causes these 0 byte reads and maybe the Socket code is buggy there. So let us know in case you can reproduce your connection drops or find out more. Regards, Patrick

bogdanul2003 commented 5 years ago

It seems that there was a missconfiguration problem regarding ADS routes on the PLC side.

bogdanul2003 commented 5 years ago

I managed to reproduce this issue on Windows. I have TWincat installed on my windows 10 and if I add a route to the PLC (as seen in the attached pic) and run the example app on the same PC connecting to the same PLC, I'll get disconnected at some point (after a few seconds). After I remove the route and try again the example application everything works fine. Also if run the example app from a VM which has a different IP then the host it works fine regardless if I add the route to the PLC or not as shown in the picture. Any suggestions why I see this behaviour ? Untitled

pbruenn commented 5 years ago

Yes, it's a known limitation. In short: TwinCAT ADS router expects exactly one TCP connection per remote IP. So it will drop the old TCP connection as soon as a new connection request is accepted. Unlike TwinCAT this AdsLib doesn't automatically reconnect. So what happens is: TwinCAT router opens TCP to target example app opens new TCP to target TwinCAT router TCP gets dropped TwinCAT router reopens TCP to target example app TCP gets dropped example app gives up

Here I tried to explain this in more detail: https://github.com/Beckhoff/ADS/issues/14#issuecomment-362547370 https://github.com/Beckhoff/ADS/issues/30

bogdanul2003 commented 5 years ago

Thanks.