TCP/IP communication reconnection issue

Hello Everyone,
I am trying to connect 4PP450 panel (client) to 3rd party device (server) through TCP/IP protocol. At first instance, when I enable the communication, client connects server immediately and after disabling it gets closed as well. but for next instance when I try to connect to server again, B&R PLC 4PP450 is taking almost 15-20 mins to reconnect. In between if I restart the PLC, it gets connect immediately. How to diagnosis this issue

I assume that functions are used from the AsTcp library.
After opening a socket, the LINGER time can be changed for the socket with function TcpIoctl() function (tcpSO_LINGER_SET). This will then cause a faster reaction for the TCPclose function and subsequent TcpOpen() function.
As far as I remember this is also present in the sample packages.

1 Like

Hi,

in addition to what Corne wrote:
it could be possible, that also the 3rd party device (the server) is part of the long(er) reaction time until TCP connection is re-established.
If the server does not close the socket after the client has closed, then you could ran into a so-called half-open TCP connection. That means: the server still thinks that the “old” communication channel is active, while the client already tries to establish a “new” channel… under some circumstances, the client has then to wait until the server does a shutown and restart on his side.

To diagnose if a half-open connection is root cause, a wireshark trace of the TCP communication is needed.
Also, it would be interesting, if the “fast reconnect” is also happening if the server device does a restart instead of the client.

Best regards!

Hello Alexander,
I tried to test in the same way you suggested. B&R PLC does not connect to server, even if server has a clean restart. still client is taking longer time to reconnect

1 Like

Hello Corne,
I have checked Tcploctl() function block in sample packages, but it is not available. If you share any references, then would be helpful to solve

Hi,

okay, thanks for the update.
Based on the result of the server reboot test, I only can propose to check your handling of TcpClose() in your client source code:

  • is TcpClose() really called under all circumstances, when you want to close and re-connect after it?
  • is it called asynchronous (= cyclic call until status of TcpClose returns a status not equal with BUSY)?
  • does TcpClose() return an error, or does TcpClose() stays for a long time in status BUSY (= 65535)?
  • When calling TcpClose(), is something changing when setting the “.how” to “tcpSHUT_RD | tcpSHUT_WR” (please see here for details B&R Online Help)

Best regards!

The call to the TcpIoctl seems to be removed.
The function block TcpIoctl is still available in the .typ file used in the samples and also the linger_opt structure is still available.
The extra step before the TcpClose call, should be someting like this.

	35:
		Client.linger_opt.lLinger := 0; (* 0 second *)
		Client.linger_opt.lOnOff := 1; (* Close as fast as possible *)
		Client.TcpIoctl_0.enable := 1;
		Client.TcpIoctl_0.ident := Client.TcpOpen_0.ident;
		Client.TcpIoctl_0.ioctl := tcpSO_LINGER_SET;
		Client.TcpIoctl_0.pData := ADR(Client.linger_opt);
		Client.TcpIoctl_0.datalen := SIZEOF(Client.linger_opt);
		Client.TcpIoctl_0();
		IF (Client.TcpIoctl_0.status = 0) THEN
			Client.sStep := 40;		
		ELSIF (Client.TcpIoctl_0.status <> ERR_FUB_BUSY) THEN
			Client.sStep := 40;		
		END_IF