Controller drops TCP connection

[abradford]

Hi all,

I'm having two issues with my F2424 controller.  First, the controller seems to close TCP connections without reason during data transfer, and second, the STATUS(3) command doesn't detect the closed connection.

What happens is the controller connects to a central server to upload a sensor log, but sometimes during the data upload the TCP connection is dropped.  The server sees a 'Connection reset by peer'.

There doesn't seem to be a way to detect the dropped connection on the PLC, as STATUS(3) call in the following code is ineffectual in stopping the loop.  When the connection drops, the controller is unaware and continues trying to upload the data.

Any help will be much appreciated!
Andrew


This is the code that is affected by the dropped connection:

Code: [Select]

' loop through the controller log
   WHILE I < N
' offset from start of log
      O = DM[34] + (DM[30] * DM[32])

' format data to send (6-char ascii number)
      A$ = STR$(DM[O], 6)
      A$ = A$ + STR$(DM[O + 1], 6)
      A$ = A$ + STR$(DM[O + 2], 6)
      A$ = A$ + STR$(DM[O + 3], 6)
      A$ = A$ + STR$(DM[O + 4], 6)
      PRINT# 4 A$

      ' Erase log entries that have been sent
      DM[O] = 0
      DM[O + 1] = 0
      DM[O + 2] = 0
      DM[O + 3] = 0
      DM[O + 4] = 0
      ' Bring the start index up to speed
      DM[30] = (DM[30] + 1) MOD (DM[33] / DM[32])

' if the connection is closed, close our end down
' and log an error
      IF STATUS(3) <> 1 THEN
         PRINT# 4 "</>"
         DM[DM[40]] = DM[DM[40]] | 4
         RETURN
      ENDIF

      I = I + 1
   ENDWHILE


[support]

Is the server running on a PC? Is the server on the same LAN or over the Internet?  How often is the connection broken?

Is there a way for us to test it? i.e. if you configure the router to map the server port so that it is accessible via the Internet we could test the connection. Alternatively if this is a simple server software you could email us a copy (if authorized) to run on our PC so that we can test it. We can also test the STATUS(3) function to check your observation.

You should only make a TCP connection just before uploading the sensor data and close the connection after completion. An open connection will time up after some time.

One other way to check against close connection besides using STATUS(3) is to start a timer before uploading and if the timer expires it is most likely connection has been lost.

E.g.   TIMERPV[10] = 50  ' setup a 5 second timer on timer #10

WHILE ....
   ......
   IF TIMERPV[10]=0 GOTO @10

ENDWHILE

@10   ' destination for breaking from the WHILE loop.

[support]

We tested using Modbus/TCP client connection to a Modbus TCP server running on a PC. We found that an open client connection with no activities for 1 minute will automatically be closed by the PLC's operating system. Unfortunately, STATUS(3) did not return a 0 when polled in the case of automatic closure until the program attempts to send another Modbus/TCP command, then STATUS(3) returns 0.  

So our advise is try not leave a client connection open if it is to idle for more than a minute. Close the connection when not use and then reconnect when needed. Also if a connection is not closed then it will deny other custom functions from using the client socket for remote TCP connection.

We do agree that ideally STATUS(3) should return 0 when polled in the case of auto-closure of idle client connection, so that the PLC program can detect the closure before attempting to send a query command. We will report this as improvement suggestion to the R&D and should have this fixed in the future firmware releases.

[abradford]

Hm, sorry for not replying sooner.

Thanks for looking into this for me.  If it's still relevant, the controller is connecting over the LAN to a PC running the data-receiving server.

The connection is broken seemingly randomly, and not when idle.  The connection drops in the middle of sending data.
The program on the controller connects, sends data, and disconnects.  The connection is never open for more than 30 seconds, depending on how much data needs to be sent.  My controller usually sends between 180 and 1260 characters in a transmission.

I've addressed the issue by developing a more robust transfer protocol that acknowledges every message and aborts if no acknowledgement is received.

Unfortunately, I'm not authorized to share the codebase.  You may be able to recreate the issue by setting up a listener using the UNIX program 'netcat' and configuring a controller to dump memory to the server.

I still see the dropped connections, but since I'm not losing data it's no longer an issue that I must solve.

Thanks again!
Andrew

[support]

Thanks for your reply. We are glad that you have managed to resolve your problem.

Is the PC connected to the LAN via Wi-Fi? We did some test with a F-series PLC making a client connection to the another server. What we found are quite interesting:

1) Two F-series PLCs are connected to a network router. One F-series make a Modbus/TCP client connection to the other F-series PLC running the Modbus/TCP Server. We can maintain 100% connection without any loss connection for hours.

2) One F-series PLC is connected to a network router. A PC is also connected to the same router using Ethernet cable.  The PC is running a Modbus/TCP server application program called "Modbus Slave" produced by www.modbustools.com. Modbus Slave provide  statistics showing the number of Modbus/TCP command received and the number of command sent as well as error counts. Again with both PLC and PC connected to the router via Ethenet there were very few loss packets.

3) Same as above but the PC is connected to the LAN via Wi-Fi. We immediately notice that there are more frequent loss packets. Once in a while the PLC would not get a response from the PC Server after it has sent a Modbus/TCP command. The PLC would see a comm failure (STATUS(2)) and does a resend and communication could continue.  However, we did not notice any loss socket connection even in such an arrangement.

Given the fact that not all packets always arrive as expected, you have taken the correct approach in using a more robust protocol to exchange information with the server. A protocol such as Modbus/TCP is quite robust and is already available free on the F-series PLCs via built-in READMODBUS, WRITEMODBUS, READMB2 and WRITEMB2 commands.

[abradford]

If only it were a case of bad wireless; but the controller is connected with ethernet.

I had researched using the MODBUS protocol instead of the custom protocol.  In the end I decided that MODBUS is too low-level and device-specific.  My server has to accept connections from a variety of controllers, and can't know anything about the controller internals.  MODBUS address mappings may change between controller models or manufacturers.

On the other hand, it certainly hasn't been a walk in the park developing the custom protocol

Thanks!
Andrew