Re: Ethernet/IP Device Support and CompactLogix

[Kay-Uwe Kasemir <kasemirk@ornl.gov>]

Hello:

Thanks for tracking this down!

500 is a value that happens to work right now for all the  
ControlLogix PLCs
at the SNS, but that is based on luck, not a full understanding of  
the real limit.

The header file ether_ip.h has some comments
about my (failed) attempts to figure this buffer limit business out.
I found no specific buffer limit in the protocol specification.
Tests with an AllenBradley ControlLogix PLC went like this:
When reading elements of an SINT array, I could pick the
_response_ packet size pretty much to the byte by asking
for more or fewer array elements (SINT==8bit byte).
From that, it seemed that the PLC could send a response
of 538 bytes, not one byte more.

So in that case, it seemed obvious that the PLC _response_ was
limited to 538 bytes, while you now found a _request_ limit of 548.

It's been unclear to me if the limit of 538 in the response
applies to the total byte count for the whole
protocol wrapper + status codes + meta info + actual data,
or if some of the protocol wrappings don't count.

-Kay

On Jun 29, 2007, at 16:21 , Mike Forster wrote:

> Hi folks,
> Just an update on our EtherIP with CompactLogix use:
> We are communicating smoothly with the PLC at this point after  
> sorting out an anomaly.
>
> We saw that when a record scan list became long (too many records  
> with the same scan rate), all the elements in that scan list would  
> stop responding.  Eventually we traced this down to the  
> EIP_buffer_limit which was the default 500.  This limit at 500  
> allows data to be sent that is 554 bytes long.  After some trial  
> and error we found that the PLC responded correctly if the data  
> sent was 548 bytes long or less.  When we set EIP_buffer_limit to  
> 494 our problems went away.
>
> Mike Forster with John Dobbins
> LEPP
> Cornell University