0

Details: I am dealing with an issue interfacing to a Modbus over TCP/IP device. We are required to poll a section of the devices modbus registers 4-6 times a second. We have recorded the following times. In control tests, we have been able to communicate at the following speeds:

Control Device: once every 0.0015s with a standard deviation of 0.0001s.

Issue Device: once every 0.5200s with a standard deviation of 0.01s.

After weeks of troubleshooting and packet capture, we had narrowed down the issue to the fact that the device we are communicating with is not issuing, or responding to, TCP handshake packets. However communication is still possible as the query still proceeds exactly 0.3200s after the TCP request is issued and subsequently ignored. Additionally, the issue device Does not support UDP.

Photo of packet capture breakdown [1]: https://i.stack.imgur.com/lCEos.png

The first (top) packet is the control, and the second (bottom) packet is the issue

Question: Ignoring the fact that the fundamental role of TCP is handshaking, is there a way to reduce, or mitigate entirely, TCP handshaking on an Intel NIC on a Windows 7 machine.

Community
  • 1
  • 1
Pixel
  • 1
  • 5
  • Use persistent connections. NB The fundamental role of TCP is to be reliable. Handshakingg is only one of several mechanisms tothat end. – user207421 Feb 05 '18 at 22:53
  • Thanks for that response EJP. That has given me a new trail to look into. – Pixel Feb 06 '18 at 13:15
  • Would TFO help? (TCP Fast Open) – FormerNcp Feb 06 '18 at 21:46
  • Persistent connections would help a lot more. @FormerNcp – user207421 Feb 08 '18 at 02:10
  • I agree EJP. It seems that there is a disconnect between the traffic to our control device and our issue device. With our control device, our Modbus via TCP/IP function block sends a [FIN,ACK] packet after a response to a query, but with our issue device, it only sends and [ACK]. We are looking into it more, but the function block is 3rd party and a bit of a black box. We have been in contact with the creators though, and I will update with an answer when I get one. – Pixel Feb 08 '18 at 12:35

1 Answers1

0

The issue is the requested buffer size from the PLC. We got in contact with the developer of the TCP/IP Modbus server software (same as the PLC manufacturer) and found that the default requested buffer size was 2GB which was too much for the Modbus device we were communicating with. We have a new version of the TCP/IP Modbus server that has a configurable buffer size, and are communicating at 10ms.

Pixel
  • 1
  • 5