Experimental Physics and
Industrial Control System

Hi:

Good that you narrowed it down to some tags!

For what it's worth, try to update to the latest from https://github.com/EPICSTools/ether_ip .

In May 2018(!), the constant 'Funstuff' string that you see has been replaced with a cycling hex number string that's used to detect mismatched request/reply messages.

Also for what it's worth, I think you are taking a huge performance hit.

Just based on the tag names, what you're reading looks like boolean information: XXX_Open, YYY_Trip, ... So it's just one bit of data per tag.

When you're reading these as individual tags, handling each one becomes a read request.

If you made them elements of a BOOL[] array, or bits in a DINT or DINT[] array, the driver would read that array tag in a single read request.

In your ladder logic you will of course prefer to deal with 'Flow1.Below_Set_Point_Trip' and not 'SomeDINTTag[3].4', but you can add alias tags for that.

See 'Guidelines' in https://github.com/EPICSTools/ether_ip/blob/master/ether_ipApp/doc/readme.txt#L141

Back to your specific error:

Is there no problem with any particular tag, i.e. each tag works fine when you run a database file with just one record for just that tag name?

Does the error happen as soon as you include records for one tag too many, doesn't really matter which tag name?

--> Try lowering the EIP_buffer_limit.

Your tag names are actually structure elements. So 'Flow1.Below_Set_Point_Trip' is tag 'Flow1', segment 'Below_Set_Point_Trip', and the names are quite long.

The response for each is tiny (one bit), but wrapped into "here's the response for that request, it's a bit, it's a byte long (since that's the smallest thing we can return), status is OK, there's no extended status, plus here's a reserved/unused padding byte". So overall, there's a lot of protocol overhead. Your error message shows a problem when 14 tags got combined into one MultiRequest.

With a PLC buffer size of around 500 (exact size unclear, see https://github.com/EPICSTools/ether_ip/blob/master/ether_ipApp/src/ether_ip.h#L123 and https://github.com/EPICSTools/ether_ip/blob/master/ether_ipApp/doc/readme.txt#L883), that leaves about 500/14 = 35 bytes for each tag's request resp. response. Just the encoded path name for 'Flow1.Below_Set_Point_Trip' uses around  30 bytes, so 14 requests could hit that PLC buffer limit.

That would explain why the PLC replies with "invalid data length", it's trying to tell us: You sent me a request that I cannot handle, it's too long.

In the latest sources, the EIP_buffer_limit defaults to 480.

So add this to your st.cmd:

# Use 480 or smaller, like 450

EIP_buffer_limit(480)

If you lower the EIP_buffer_limit, the driver will combine fewer tags into one MultiRequest, and the PLC should be happy.

The downside is of course that you then have more network round-trips: Instead of one MultiRequest with 14 tags, it'll be one with 10, followed by one with 4.

Combing the data into arrays helps minimize the number of requests.

Thanks,

Kay

From: Guerra, Roy Ignacio <[email protected]>
Sent: Wednesday, January 15, 2020 6:06 PM
To: Kasemir, Kay <[email protected]>; [email protected] <[email protected]>
Subject: [EXTERNAL] RE: EtherIP EPICS Support: Invalid Service 0x52