S7-1200 TSEND_C Problem

Hello all,

I have sucessfully implemented a connection of 2 S7-1200 PLCs over a VPN using TSEND_C and TRCV_C open communication blocks (UDP).
I want to produce an error bit when the connection is dropped.
The intention was to use the ERROR bit from the TSND_C block. I used that but it does not work.
When the PLCs are online and the connection is ok then the data exchange works perfectly. If I disconnect power to the VPN router at the TRCV_C end,
the TSND_C end does not understand it and it does not produce an error. It looks like the TSND_C thinks the connection is stil valid and that data exchange is happening as it produces a DONE bit.
Any suggestions on how to resolve this will be highly appreciated.

Regards
Nik

Thats how UDP works. There is no acknowledgement that the partner has received the data.
And as UDP is connectionless, there is no valid or invalid connection.

If you want to know that the partner is there and has received the data, with UDP you need to implement the acknowledge on your application layer. For example, add a telegram counter to your UDP telegram, and the partner sends an UDP telegram with the counter value back, to confirm that the data has successfully been received.

I would simply use TCP, then this all is done automatically.

I was almost certain that this was because of the UDP. Well I chose UDP as it is less traffic hungry and the application is based on 3G. The VPN is Open VPN UDP. I am not sure if it will work having the VPN tunnel,set as UDP and then have TSEND_C - SEND_C connection in TCP.
Can you please elaborate on your suggestion about the telegram counter?

grnick50 said:

Can you please elaborate on your suggestion about the telegram counter?

Click to expand...

I would use an integer as first element in your send dataset. And each time you call the tsend-function, increment the counter by one. Also remember that with UDP it's not guaranteed that the telegrams arrive in the same order as you have sent them. With the counter value the partner can detect older telegrams and discard them. The order can be a problem if you send counter values for example.

If you only want to know if the other partner is alive, then the partner may send every 30 seconds or what you need an UDP telegram with only a counter value.

I typically use a heartbeat - as part of your telegram, read a BOOL tag from the remote PLC which toggles on and off at a set interval. If you see the tag retain the same state for, say 10 seconds, you know you've lost the link.

The drawback with this method is that if your data polling syncs up exactly with your toggle frequency, then you could be reading it in the same state every time even though it's changing in between. This problem could be amplified by using a VPN over 3G which may have larger latency than a direct network connection. So, that's where the "telegram counter" suggested above comes in. You can approach it similarly to the heartbeat - just have a value increment every second in PLC1, (don't forget to include a reset at say 100), read it in from PLC2, and just make sure it keep changing. Again, if you see the same value coming back for 10 seconds or so, you've lost the link.

Or (as I think was suggested above), you send a value to the remote PLC, the remote PLC reads it and sends the same value back. As long as you get that value back, increment your value and repeat - if you don't, you know the message has gotten lost somewhere.

grnick50 said:

I was almost certain that this was because of the UDP. Well I chose UDP as it is less traffic hungry and the application is based on 3G. The VPN is Open VPN UDP. I am not sure if it will work having the VPN tunnel,set as UDP and then have TSEND_C - SEND_C connection in TCP.
Can you please elaborate on your suggestion about the telegram counter?

Click to expand...

Theoretically, a VPN tunnel shouldn't care what traffic goes through it, whether TCP, UDP, or anything else.

mk42 said:

Theoretically, a VPN tunnel shouldn't care what traffic goes through it, whether TCP, UDP, or anything else.

Click to expand...

But UDP has less overhead that TCP. If you have a volume based mobile account (e.g. 100 Mbytes per month), than maybe you can use a cheaper one of you have less traffic with UDP than TCP.