Mark Short

In the Forward Open message of EtherNet/IP, there are two Network Connection Parameters, one for Originator->Target, the other for Target->Originator. Volume 1 of the CIP specification (3-5.4.1.1) describes the fields of the Network Connection Parameter. It explains the role Redundant Owner field for the Originator->Target direction, but makes no mention of its role for Target->Originator. Am I right to assume that the Redundant Owner field has no role in the Target->Originator direction, and is ignored?

I am developing software in C++ to communicate with Allen Bradley devices using EtherNet/IP.To improve performance, I am using the Multiple Service Packet service to encapsulate (i.e. bundle together) many Read Tag services. I restrict the number of services I encapsulate so that neither the request nor the reply exceeds the connection size.It works OK most of the time, but occasionally I get a Multiple Service Packet replay with General Status = Embedded Service Error, and the last two of the encapsulated Read Tag replies have General Status = Partial Transfer. I interpret this as the ControlLogix device saying that the message it's been asked to generate is too large for its connection size. In this error case, the reply would occupy 4002 bytes, and the connection size is 4002 bytes, so I would expect it to be OK. The ControlLogix seems able to create messages up to 3992 bytes in size.I measure the reply size by counting (inclusively) from the CIP sequence count to the end of the packet. This is based upon my interpretation of Volume 1 of the CIP Spec, section 3-5.4.1.1, where connection size is defined.Any suggestions why the ControlLogix device is unhappy generating a message of 4002 bytes?

FWIW my experience with the Large Forward Open service and Allen Bradley devices is that the Logix range will only support a connection size of about 4000 bytes, whereas the Micro800 devices support the full 65511 byte connection size.

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 understand only appears in Wireshark's translation of the raw bytes. So I think Wireshark is not translating CIP correctly.  

I am working on 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 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 site, and haven't found out what the latest version is.) Or is it that I just haven't understood the gnarly structure of CIP messages correctly? Thanks in advance.