ControlLogix5561 EtherNet/IP Connection Time Out Error 16#0203

Hello All,

I am trying to add a Xport-EIP-MB from Grid Connect module (Modbus to EtherNet/IP converter) in the I/O tree of the RS Logix 5000 Software for a ControlLogix5561 Processor. This is added as a generic ethernet module at it giving me a Connection Time out 16#0203 error.

I have monitored the data transmission between the Xport and the PLC using wireshark and I have attached the summary with the relevant filter AND controllogix IO setting. I have set the RPI AT 20.0ms. How I have connected the modules are; I have my PC, ControlLogix5561 PLC and the Xport Adaptor connected through a Dual speed hub.

I am sure this is something to do with the data packet transmission and I have seen on previous posts that grounding can be a issue, I have checked this and my 1756-ENBT/A EtherNet/IP card is din mounted with a ground reference. One point to note is that the Xport is RJ45 connector with a external shield for grounding which I have left not connected to the ground (As my understanding this is purely for noise cancellation) and could this possibly be a reason for packet loss.

IP - 10.0.1.104 - ControlLogix5561 PLC
IP - 10.0.1.103 - Xport Module
IP - 10.0.1.102 - PC

Can anyone guide me in the right direction in solving this issue.

A reply is much appreciated

Cheers.

What you're seeing is the ControlLogix establishing an I/O connection to the XPort and then running it for exactly 100 cyclic transmissions... then just stopping. I don't know if the 100 cycles is more significant than the almost exactly 2 seconds that the connection runs.

Note the SEQ number on each transmission; the ControlLogix stops at SEQ=100 and the XPort transmits four more times, getting to SEQ=104. Timeouts in EtherNet/IP are generally 4 x the RPI, so it makes sense that the 1756-ENBT stops transmitting but the XPort doesn't realize the connection is broken until 4 RPIs later.

But why.... the traffic between the 1756-ENBT and the XPORT is not interpreted by Wireshark as CIP explicit message traffic so I'd have to decode it by hand (I'm not skilled at that). I expect that it's a connection re-establishment, but I just don't know.

I think this means it's a protocol or compatibility problem, rather than a packet loss problem. Unless there's something that is preventing the multicast traffic from the XPort from reaching the 1756-ENBT, the connection should keep running. And if the multicast traffic from the XPort was not reaching the 1756-ENBT, I would expect the timeout to occur in 100 milliseconds (the EtherNet/IP minimum), not 2000 milliseconds.

Hmm.

It's also interesting that the 1756-ENBT begins its sequence numbering at 0, while the XPort begins its sequence numbering at 1. That shouldn't be an issue because sequence numbers often get out of sync because UDP packets get dropped, and the "missed packets" counter is based on the difference between sequence numbers from the remote device, not the difference between the originator and target sequence numbers.

Aha.. in Wireshark I highlighted the TCP connection then selected the "Decode As" feature and chose ENIP.

Sure enough, the 1756-ENBT is sending "Forward Close" commands to shut down the I/O connection, then three seconds later sending a "Forward Open" command to open up a new one. This is intentional on the part of the 1756-ENBT, so we have to figure out why the -ENBT gets disenchanted with the I/O connection after only 100 cycles.

Thanks Ken

Ok this seems like an attribute setting on Xport config file, but for my understanding that should NOT effect the connection between the PLC and Xport...

I have left the the attributes on there default values...it is define by this; I have copied and paste the data from the Xport manual..

----------------------------------------------------------------
--Modbus Master Timings & Behavior (Attributes 119,
120, 121, & 122)--

The Modbus Master inside the XPort has a loop that continually reads and writes the registers of the Modbus slave. These attributes allow you to tune the behavior of the Master and adjust how fast it operates. These can be useful if you want to speed-up the Modbus Master to boost performance or slow it down if your Modbus Slave’s processor cannot keep up.On every loop, the Modbus Master performs the following in this order:

* Send Network Status LED Message (if necessary)
* Send Module Status LED Message (if necessary)
* Send Modbus Read Messages
* Send Modbus Write Messages (if necessary)


The attributes to control the behavior are defined as follows:
* Modbus Master Inter-scan Delay – The number of milliseconds the Master will delay between every scan loop before executing again. The default is 100 milliseconds.

* Modbus Master Inter-message Idle Time – The number of milliseconds the Master will delay after the end of the receipt of a Modbus response until sending the next Modbus request. The
default is 10 ms.

* Modbus Master Output Heartbeat – The number of milliseconds that must elapse before the Master will send a Modbus Write command for output data if it has not changed. The default
is 0 ms, which means output data will be written on every scan, regardless of whether it has changed or not. Setting it to 0xFFFF will disable the heartbeat entirely and output data will be written only after a change.

*Modbus Master NS/MS LED Heartbeat – The number of milliseconds that must elapse before the Master will send the Modbus message to write status of the EIP NS/MS LEDs (ifconfigured) if they have not changed. The default is 0 ms, which means the LED status will be written on every scan, regardless of whether it has changed or not. Setting it to 0xFFFF will disable the heartbeat and the LED status will be written only after a change.
The valid range for all of these attributes is 0 to 65535 (0xFFFF) ms.
Note for the heartbeat timings – if the normal execution time of one loop/scan is, for example, 200ms,then setting the heartbeat attribute value to anything between 0 and 200 ms will still cause the message to be sent on every scan.

----------------------------------------------------------------

This is interesting..

Cheers

Problem Solved

Hello All and Ken,

Found the problem after playing around with Wireshark capture. The wireshark trace shows my Xport is configured to provide something like 128 bytes of data.

On RSLogix I have specified the input, output connection parameter data size to be 1 word of data in each direction.

After quering the data sizes from the Xport module, I have found that Input to be 16#0041 (65 decimal)Output to be 16#0001 (1 decimal). If I enter these decimal values to the connection parameters I get a uninterrupted connection to the Xport from ControlLogix5561 :site:

Awesome :nodi:

I'm kicking myself for overlooking that. Great work.

The Forward_Open command sets up the size of the connection from the Originator to the Target (the ENBT to the XPort) and from the Target to the Originator (XPort to ENBT).

The sizes are 8 bytes and 4 bytes, respectively.

When the connection starts up, the XPort delivers the much larger data packet that its internal configuration requires, and the ControlLogix realizes that this is not the data it asked for, so it sends out a message (Forward_Close) to shut down the connection, then tries again.

"A cheeseburger, and fries, please."
"Here's 130 cheeseburgers, extra pickle."
"Cancel that order. I want a cheeseburger, and fries."
"Here's 130 cheeseburgers, extra pickle."
"Cancel that order......"

Thanks for sticking with the issue, and for posting your followup !