Sign in to follow this  
Followers 0
Mark Short

EtherNet/IP - Multiple Service Packet

4 posts in this topic

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?

Share this post


Link to post
Share on other sites

Just a wild guess and no specific knowledge to back it up, but I surmise that there are about 10 bytes of parity, routing and overhead information you've failed to allow for in your plan that the CLGX is leaving room for.  Just a wild idea.

1 person likes this

Share this post


Link to post
Share on other sites

Yes, I think that's a strong possibility, but I haven't found which bytes it is that I'm not accounting for. The EtherNet/IP spec is not very explicit when it comes to the connection size. I haven't had this much fun with a protocol since ISDN...

Edited by Mark Short

Share this post


Link to post
Share on other sites

I think BobLfoot is on the right track.   You have the MSP packet overhead (the command header and the sub-packet offset list).  Then each sub-packet has its own CIP header.   Exactly how the overhead is calculated is something of a mystery to me.   I add some fudge factors based on experience.  I created a tag that was big enough to fill the entire packet (1000 DINT), and then did a read to see what I got back.  The I counted backward 4002 bytes to see where that lands in the protocol layers.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0