Micrologix 1400 TCP Retransmission

k4r3s

Member
Join Date
Oct 2013
Location
Belgrade
Posts
2
Hello, experts!
I poll some holding registers on Micrologix 1400 through Modbus TCP. The PC and the PLC are connected directly with Ethernet cable without router or switch. I have noticed TCP retransmission in every polling cycle. The PLC sends identical data two times. Does anybody have a cure for that?
As a next step I want to put this communication to radio network that's the reason why I need minimal data transfer.
I attache a Wireshark screenshot of the recorded communication.
Thanks! :)
ModbusRetransmit.jpg
 
Welcome to the forum. This looks like TCP delayed ACK behavior.

One of the services that TCP provides is reliability; it does this by sequencing each byte of data and retransmitting if data is loss is detected. The detected part is important - it doesn't mean data loss occurred, it just means that it was detected. In your case, if you look at the retransmission time (this would be the server side RTO, round trip timeout) it is just about 100ms. When the server puts bytes on the wire (MAC address says VMWare device, but you claim a Rockwell PLC, not sure why, or if it matters) it starts a timer. If it does not get ACK before the timer expires (RTO), it resends the data.

Client side behavior has an optimization called delayed ACK. It does not want to send an ACK for EVERY packet - it waits a little while to see if it has some data to send back, so will then send data and the ACK at the same time. More efficient. In your case, you have no data to send back quickly, but there is a timer here too - the delayed ACK timer. I don't know what OS you are using, but WindowsXP says 200ms (https://support.microsoft.com/en-us/kb/328890). So it will wait that long before sending a response, even a discrete ACK. Notice the timing mismatch - server waits 100ms before timing out, client is waiting 200ms (or whatever, but longer than 100ms). So you get a true TCP retransmission every Modbus request cycle. This is a generalization; it's actually more complicated. RFCs and google can keep you busy for quite some time on the topic, as could Steven's book.

Some of these values are adjustable by the user - Windows has the registry entry, and Linux can adjust RTO values per route (http://indcontrolproto.blogspot.com/2014/02/tcp-timing-and-rto.html).

Anyway, this is not unheard of. It's not great behavior but usually networks are over provisioned so this has little impact. In your case with radio communications, I think you are correct to be a little concerned as this could waste precious bandwidth. Since the Rockwell device is embedded, the timers are likely all fixed. Worth asking Rockwell if there is a way to adjust, but I would not expect a good response. So if you feel this will be a real issue, focus on the client side. Might need to move your Modbus poller to a different OS or system that has more hooks or at least different behavior to avoid this.
 
Thanks!
I have disabled the TCP/IP delayed ACK feature in registry and now there are no retransmissions.
I appreciate your help. It significantly reduced the poll cycle. I have close to 100 PLCs on radio network :)

PS:
For testing purpose I'm using WinXP inside VMWare.
 

Similar Topics

Iam facing a Problem in micrologix 1400 communicating with Modbus TCP. I need to Read Some Register Data. on testing with modscan its showing...
Replies
8
Views
3,069
Does anyone know if the MicroLogix 1400, Series B, can handle both Modbus RTU & Modbus TCP at the same time? I am working on a project that has...
Replies
4
Views
3,110
Hi all, Question straight up: if I have a micrologix 1400 with a value of 1234 in register N7:0, how can I convert that value to ASCII values and...
Replies
6
Views
5,890
Hello, I have been working on a Micrologix 1400 Rev B trying to get it to request Modbus registers via Ethernet. It is connected to a Rosemount...
Replies
6
Views
5,090
I want to read micrologix 1400 plc data with register address with the help of java program on ethernet using tcp ip. Please anybody help me...
Replies
5
Views
4,784
Back
Top Bottom