EtherNet/IP Forward Open

I am developing software to communicate with Allen Bradley PLCs via EtherNet/IP.

I'm very much in the foothills at the moment, trying to figure out how connect to the PLC using the Forward Open message, by looking at Wireshark traces between Rockwell's Connected Components Workbench and a Micro 850 device. The Forward Open request makes sense, but the Forward Open response has a Request Path in it that I can't make sense of. It appears after the Additional Status Size field. The definition of the Message Router Response in the CIP spec doesn't include a path (but the Message Router Request does). After the Request Path comes the Forward Open Response bytes, which is what I expect to see.

It does occur to me that my copy of the spec might be out of date. I have Volume 1 Common Industrial Protocol (CIP), Edition 3.3, dated November 2007. (I've looked on the OVDA website, but doesn't indicate the latest version is.) Or is it that I just haven't understood the gnarly structure of CIP messages correctly?

Hi Mark,

Mark Short said:

I have Volume 1 Common Industrial Protocol (CIP), Edition 3.3, dated November 2007

Click to expand...

I dont know much about what you are doing but some food for thought that may help

The Micro800 communicates using serial Modbus RTU with EtherNet/IP being added to highest level controller in 2013.

Click to expand...

https://www.automation.com/automation-news/article/micro800-standalone-machine-controller

So your publication 2007 was wrote long before they came out... not that it would not work, just something to think about

Best of luck

What you are looking at is not actually the Forward Open Response, but the Message Router Response which is essentially a header/carrier for CIP packets. Check Section 2-4.2

The Response Data section is the actual Forward Open Response Packet as defined in Section 3-5.5.3

Archie,

Thanks for your reply.

I went back to the Wireshark traces, and looked at the actual bytes sent/received, and they do correspond with the CIP specification. The Request Path that I couldn't explain only appears in Wireshark's translation of the raw bytes. So I think Wireshark is not translating CIP correctly.

The wording of the text you quoted is subtly different from the version of the spec I have, so I suspect I do have an out-of-date version.

Mark Short said:

So I think Wireshark is not translating CIP correctly.

Click to expand...

The Wireshark dissector for CIP/Ethernet/IP does not fully dissect all packets. If you find an actual error in dissection (e.g. wrong label for property, bad value conversion), not a failure to dissect a packet, and post the error on the Wireshark forum with a trace example the maintainer will correct it. At least that is my experience.

You might get a packet not currently decoded added to the logic for decoding if you provide a trace and a breakdown of the bytes. That was my experience when working on DNP3.

I am now moving on to establish an EtherNet/IP connection using the Large Forward Open service, so that I can send/receive bigger packets.

With either a ControlLogix or CompactLogix device I find that if I request a connection size of 65511 the device responds with Resource Unavailable. From my reading of the EtherNet/IP spec I would expect it to reply with Connection failed and an Additional Status of Invalid Connection Size, Invalid Originator To Target Network Connection Size or Invalid Target To Originator Network Connection Size. If I reduce the requested connection size to 4082, the device does respond with Invalid Connection Size. And if I reduce the connection size to 4002, the request succeeds.

I can work around the fact that the device sends the Resource Unavailable message when I request a large connection size, but it makes my code a bit more complicated, as the Resource Unavailable doesn't suggest what the maximum connection size should be. What is happening when the connection size is reduced to 4082 to cause the Logix device to change its response?

Mark_Short: One quick question. Is you application an HMI application?
Normally Forward_open is required to establish implicit or cyclic connections. This requires very deep knowledge of the CIP specification.
If your application is HMI, may I suggest thinking instead of using UCMM (unconnected message manager), and then you can implement PCCC commands to access tags in the Logix program, and even system commands.
Sorry, maybe you do need Forward_open or Large_forward_open for some reason that I do not understand now, in which case this post is not helpful.

AlfredoQuintero said:

...maybe you do need Forward_open or Large_forward_open for some reason that I do not understand now...

Click to expand...

If the device supports large forward open.

One reason; read/write arrays larger than about 500 bytes in one transaction.

Ethernet/IP variants:

- Explict/Implicit messasing
- Connected/Unconnected
- SLC/CLX
- CLX/Micro 800

And a multitude of functions such as the mentioned large open, multiple tags in a single request, reading entire structures ... that some devices support and others do not.
A real mess.
Furthermore, the available documentation is scarce and the main part of it is not free.
I wrote an Ethernet/IP driver for SLC and another for CLX and it cost me more than the much more complex one that I wrote for OPC UA

Mark- said:

If the device supports large forward open.

One reason; read/write arrays larger than about 500 bytes in one transaction.

Click to expand...

Mark: The limitation of 500 or so bytes for normal Forward_open is for implicit messaging, which is the kind of communication used for IO control, such as a PLC controlling motion device. But the original inquiry refers to an HMI application. If the HMI application does not need critical/cyclic communication, I think it will be more simple to use UCMM because there is no need to maintain a connection and can support more than 500 bytes, as UCMM is based on TCP/IP and can fragment large chuncks of data. Forward_open and Large_Foraward_open are used to establish implicit messaging and explicit messaging connections, which need to be maintained and this means implementing correctly the so called Connection Manager object and its many mandatory instance attributes. There are companies that sell the communication stack which accomplishes this task. It is no trivial undertaking, IMHO. But sometimes engineers such as IFE manage to do it, but as he says, at a considerable cost.

Thanks to all who've replied to my query.

Yes, I am working on an HMI to access Allen Bradley devices. Our customers want to use EtherNet/IP, not DF1, so that is what we are implementing. At the moment the system sets up a connection with TCP and then polls the Allen Bradley devices. I am starting to use Large Forward Open so that I can use bigger packets, which hopefully make the polling quicker. But if it doesn't deliver the increase in speed we may need to look at setting up a UDP connection, and getting data back from the devices through unsolicited messages.

Ironically, the Micro800 devices support a packet size of 65511, but don't support the Multiple Service Packet Service, whereas the Logix devices which do support the Multiple Service Packet Service only support a packet size of 4002.

AlfredoQuintero said:

Mark: The limitation of 500 or so bytes for normal Forward_open is for implicit messaging, which is the kind of communication...

Click to expand...

It is the limit of a single message to/from the PLC because of buffer size. Reading tags via multi service request is limited to the buffer size for a single message.

I do not think the OP was asking about connected or unconnected and the pros and cons of each.