ControlLogix Message Error 16#001b - Bridging failure, Response packet too lage

mihiri

Member
Join Date
May 2010
Location
Newcastle
Posts
22
moz-screenshot.png
moz-screenshot-1.png
moz-screenshot-2.png
moz-screenshot-3.png
moz-screenshot-4.png
moz-screenshot-5.png
Hello All,

I am using a ControlLogix5561 PLC Message block of the following configuration;

Message Type - CIP Generic
Service Type - Set Attribute Single

This message block is used to configure a Xport-EIP-MB Modbus to EtherNet/IP Adaptor Configuration Settings.

I have attached a screen shot of the Error window details. I can't seemed to figure out the error produced by the Message :

Error Code - 16#001b
Error Text - Bridging failure, Response packet too large for network..

Can anyone help me on this matter..
A reply is much appreciated,

Regards,
Mihiri

ControlLogix Message Error.jpg
 
I've never seen that specific error code. CIP can transport 510 bytes in a single message, and from what I've read of the XPort user manual, that message should only return a short "Success" response.

Do any other messages to the device succeed ?

Is there a data size mentioned in the error message ?

You might need to capture this exchange on Ethernet using Wireshark and a mirror port to be sure what's going on.
 
Hello Ken,

Thank you for your quick response. That's what surprised me as well, the error code doesn't seemed to make sense in the response size. I am able to configure all the other parameters on the Xport Configuration file (Config.bin) without any issue. I encounter this specific issue When I am trying to set the Modbus Mappings - Object Class (0x65), Attribute ID (0x65) {Which maps the Input EtherNet/IP to Modbus Mapping).

Furthermore there is no specific data size mentioned on the error message either.

I will try to capture data using the Wireshark
 
Hello All,

So I used the Wireshark to capture the data transmission between the PLC, Xport and the PC. Initially I made a Get_Attribute_Single(0x0E) of Identity Configuration Object (Class 0x6E) Attribute ID 0x65 to query the Xport Vendor ID. This was done using the PLC Message block for Get_Attribute_Single.

This provides me with the success response of 16#03ac , which is as specified in Xport manual CIP Vendor ID (Default 940). I am happy with this, but on WireShark I cannot see any echo from/to the Xport modules IP, which I have assigned. I can only see the data flow between the PC and the ControlLogix5561 PLC. Ideally the Xport sends the response through to the PLC message block, which I read through the RSLogix 5000 software on my PC.

I find this very interesting, technically if I do get a success response from the Xport the wireshark should capture this details.

I have pulled the modules from the larger network and created a simple network using a router and going back to my earlier issue I still encounter the error code 16#001b (Bridging failure, Response packet too large for network). Which I can't seem to resolve and wireshark is not aiding me to debug the issue.

Can anyone point me if I am doing something wrong or technically there is an issue with incorporating a Xport module with a Rockwell PLC.

A reply is much appreciated,

Regards,
Mihiri
 
Normally the Set Attribute Single would not expect a reply. There are some vendor situations where there is a response from this message.

Using as Service Type the "Set Attribute Single" will not allow you to enter a destination tag...(n) so try the following:

Use the Service Type "Custom"
Enter all your settings, leaving the Service Code field empty
Enter also a Destination tag, use the first element of an array with some free elements, you will leave it there just to allow the message to be completed
After completed all the required fields, set the Service Code to "10" (that is the Set Attribute Single service)
16x16_smiley-surprised.gif


You will see the Destination field becoming grayed out, but still containing your tag...

Hope this helps,


- [FONT=comic sans ms,sans-serif]fuzzy logic[/FONT]
 
Xport and AB ControlLogix5561

Hello Fuzzy Logic,

Thanks for your response. When I execute with your settings, the destination tag does not receive any data and I am still getting the same response back from the Xport Module.

I can access the data sent from Xport to the ControlLogix5561 through WireShark by implementing the modules through a Hub. I have attached the wireshark data from the Xport to the ControlLogix in this post.

This Error shown on ControlLogix5561 is very puzzling and I only receive this when I try to set ONLY the Modbus mappings (Input, Vendor Specific Object Class 0x65).

A response is much appreciated,
Regards,

Xport_Error.jpg WireShark_Response.jpg WireShark_Response_2.jpg
 
I was able to extract the actual error response sent to the PLC, through wire shark (I have attached it here). It is a CIP error. šŸ™ƒ

Help needed..
Thanks


Hello Fuzzy Logic,

Thanks for your response. When I execute with your settings, the destination tag does not receive any data and I am still getting the same response back from the Xport Module.

I can access the data sent from Xport to the ControlLogix5561 through WireShark by implementing the modules through a Hub. I have attached the wireshark data from the Xport to the ControlLogix in this post.

This Error shown on ControlLogix5561 is very puzzling and I only receive this when I try to set ONLY the Modbus mappings (Input, Vendor Specific Object Class 0x65).

A response is much appreciated,
Regards,

WireShark_Exact_Response.jpg Wire_Shark_Exact_Response_2.jpg
 
Post the actual *.PCAP file from Wireshark, either here on the Forum or in another file transfer service. It's very difficult to work with screenshots from Wireshark.

The fact that the error code shows up in the response message from the XPort is interesting.

I would have thought the ControlLogix was rejecting an over-size response from the XPort, but the XPort itself is sending a short error message indicating something about its own handling of the message.

Is this one of the packaged XPort devices from GridConnect, or have you integrated it into your own host system ? Has GridConnect given any suggestions about the problem ?
 
Hello Ken,

I have attached .pcap file in the zip. What we have done is, we have purchased a Xport-EIP-MB module from grid connect and have implemented the GridConnect Xport Adaptor into a relay which consists a Modbus Server. So basically this adaptor module converts the existing Modbus server into a EtherNet/IP server so we can talk to these in house build relays through EtherNet/IP. We have designed the relevant PCB to consist the Xport module, which works fine. If the Modbus slave fails to respond to the settings, it should throw an exception as stated in the GridConnect manual. This is a very interesting problem :).

I have sent an email to GridConnect regarding this issue, but they haven't got back to me yet with an answer.

Cheers,
Mihiri
 
Interesting stuff. The Set Attribute Single has just a five-byte payload (03 00 01 00 40), so it's not too large to route.

I think the next step is to run Wireshark while you're sending the messages that do work correctly, to see if there's something different about the data payloads or the path or the CIP objects.

Try doing a capture filter that only accepts packets with the 10.0.1.103 IP address in them; the syntax is "host 10.0.1.103". That will let you capture only the data between the Logix and the XPort so you will have the most concise capture.
 
Hello,

I got a reply back from GridConnect, and they suspect the issue is byte ordering. Since EtherNet/IP is a Little Endian Network, they suggest to swap bytes for INT data type. So technically the correct payload should be sent as 03 01 00 40 00 .

I have been playing around with the ControlLogix Message block to swap the bytes to arrange them in Little Endian format for INT types. For example if I sent the settings as attached, I get a resources unavailable error (y) since this is a define error on the Xport manual.

Interestingly enough I don't believe the settings are little endian format, for example in Modbus slave I have 64 modbus registers I have entered this as seen on the attachment 16#4000. The wire shark payload for this transfer from the PLC to the Xport is (04 00 00 01 00)-which is absolute garbage and does not anyway correlate to the settings I have set on ControlLogix5561.

To me this seems like a issue on the controlLogix 5561 byte ordering because through wireshark what I am seeing is the actual data exiting from the PLC.

Any opinions as always much appreciated,

Regards,
Mihiri

PLC Setting.jpg
 
Using a UDT could have an effect you're not expecting depending on how you defined the sub-elements of the UDT and how you addressed the UDT tag in your MSG instruction.

Is that UDT example from GridConnect, or is it your own ?

Can you post the whole *.ACD program, and the Wireshark *.PCAP file ?

I think there's an extra byte that you don't expect in the UDT, caused by the mixing of SINT and INT datatypes in the UDT definition.

When datatypes are mixed in a UDT definition, they are not packed tightly together. Instead, ControlLogix inserts one or more bytes to make the elements line up. While the three sub-elements of your UDT (one SINT, two INT) add up to only 5 bytes, the UDT is 8 bytes in size.

The "extra" byte is a zero inserted after the first element (a SINT) so that the second element (an INT) will line up against a 32-bit boundary. Two additional bytes are used to fill up the UDT after the third element (an INT).

What I would do is take the UDT tag and copy its components into a SINT[5] array individually, then use that SINT[5] array as the source of the MSG instruction.

attachment.php

attachment.php


UDT1.png UDT2.png
 
Last edited:
Hello Ken,

I really appreciate your continued contribution to this thread. I am sure we are close to nailing this issue. I have attached the .ACD and filtered .PCAP files.
 
I think that the XPort is expecting a Modbus function 03 command, right ?

Function = 1 byte
Starting Offset = 2 bytes
Number of Registers = 2 bytes

You want to read Holding registers (Function 03), starting at Register 1, for 64 registers, so you intend to send "03 01 00 04 00"

Instead, you're sending "03 00 01 00 04" That second zero has snuck in from the UDT padding.

What that means is:

Function = 1 byte = 03
Starting Offset = 01 00 (hex) = 256
Number of Registers = 04 00 (hex) = 16,384 registers

Of course, sixteen thousand registers is way too many to transport in a CIP packet, so you get the "response too large for network" error code.
 
Last edited:

Similar Topics

I have a 1756-L62 that is sending a message to give a 1769-L24ER a permissive bit to run. This system has been working fine for about 2 years...
Replies
4
Views
3,422
Hi all, I wonder if someone can shed some light on my situation? I have a complex program with a mix of ladder, SFC and structured text. All has...
Replies
1
Views
3,152
Hi all! This is my first thread here (yay). I'll try to contribute to the Automation community as much as I can and I hope this forum can help me...
Replies
2
Views
3,939
Hello, is it possible to read a message using a controllogix L61, from a SLC, that is connected to a PLC-5 that already is sending data to the...
Replies
7
Views
2,112
Hey everyone, Got called out tonight on an issue with a ControlLogix L62 processor, curious if anyone has seen anything like this before. I've...
Replies
3
Views
1,594
Back
Top Bottom