Hi:
Good that you narrowed it down to some tags!
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.
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.
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
Thanks for the suggestions!
I’ve been able to narrow down the problem to a group of tags associated with faults for a gate valve.
The group of tags are prefixed with “GV1.Fault.<name>”, where <name> is the specific fault being monitored.
There are ten tags with this prefix. Three of these tags must be commented out in order for the EIP driver to load without error.
When all the tags are included, the error displayed on IOC shell from EIP_verbosity = 10 is:
EncapsulationHeader:
UINT command = 0x6F (SendRRData)
UINT length = 0
UDINT session = 0x11029111
UDINT status = 0x00000065 (invalid data length)
USINT context[8]= 'Funstuff'
UDINT options = 0x00000000
Received RR Data
UDINT interface handle 0
UINT timeout 0
UINT count (addr+data) 2
UINT address_type 0x0 (UCMM)
UINT address_length 0
UINT data_type 0xB2 (Unconnected Message)
UINT data_length 514
2020/01/15 13:52:59.7118 EIP process_ScanList: Error in response
Tag 0: 'GV1.Fault.Opened_Switch'
Tag 1: 'GV1.Fault.Fail_to_Open'
Tag 2: 'GV1.Fault.Fully_Open'
Tag 3: 'GV1.Fault.Fully_Close'
Tag 4: 'GV1.Fault.Beam_Exposure'
Tag 5: 'GV1.Fault.No_Switch'
Tag 6: 'Flow1.Below_Set_Point_Trip'
Tag 7: 'Flow2.Below_Set_Point_Trip'
Tag 8: 'Flow3.Below_Set_Point_Trip'
Tag 9: 'Flow4.Below_Set_Point_Trip'
Tag 10: 'Flow5.Below_Set_Point_Trip'
Tag 11: 'Flow6.Below_Set_Point_Trip'
Tag 12: 'Flow7.Below_Set_Point_Trip'
Tag 13: 'Flow8.Below_Set_Point_Trip'
CIP_MultiRequest reply: invalid service 0x52
It appears to be a problem with data length?
> CIP_MultiRequest reply: invalid service 0x52..
> found some info online stating CIP service code 0x52 is an Allen-Bradley proprietary “read tag fragmented service”
We send a request with 'MultiRequest (0x0A)' content, somewhat like this:
For a reply, we expect this:
MultiRequest reply (0x0A|0x80):
ReadData reply (0x4C|0x80) data for tag 1
ReadData reply (0x4C|0x80) data for tag 2
ReadData reply (0x4C|0x80) data for tag 3
Instead of 0x0A|0x80 = 0x8A we seem to get 0x52. That's a request, not a reply.
To debug this, I would start small.
Put only one record into your database, set the EIP_verbosity high enough, and you should see that the driver sends a MultiRequest for reading just that one tag.
Add more records back in, observe how the driver sends MultiRequests for more tags. Eventually either the request or the expected response size exceeds the EIP_buffer_limit, so now it sends several
MultiRequests. At some point you should then get the error, so try to figure out when.
Is it when you add records that read tagx[0], tagx[1], tagx[2], ..tagx[100], ... so when the driver tries to read the tagx array, 100 elements, the package size is too big?
The usual response from the PLC should be 'Buffer too small, partial data only', but maybe you get a different type of error.
Hi all,
I am setting up an IOC to interface with a Control Logix 5000 PLC using the EtherIP EPICS support.
I’ve successfully set everything up and can read all but three tags from the PLC.
For the three tags that are not working, when I include them in the substitution file, I get an error displayed to the IOC shell every few seconds:
EIP connecting bleps
EIP process_ScanList: Error in response
< list of tags >
CIP_MultiRequest reply: invalid service 0x52
2020/01/14 14:14:34.5732 EIP disconnecting bleps
(‘bleps’ is the name of the PLC, and I’ve removed the list of PLC tags).
I’ve checked that the three tags which are causing the “invalid service” error exist and respond using the ether_ip_test utility, and all the tags can be queried using caget, so communication
through the EtherIP support is successful.
The problem at hand is on my MEDM display screen, red/green ovals for bool-type alarm tags show as white (color mode is set to alarm), and their “Alarm” state is “INVALID”.
Simply not including the three tags that cause the problem alleviates the invalid alarm states, and the display works correctly.
I’ve found some info online stating CIP service code 0x52 is an Allen-Bradley proprietary “read tag fragmented service”; does the EtherIP support not support this service, and if this is the case,
does anyone have experience reconfiguring the tags so they do not use this service?
Thanks!
--------------
Roy Guerra
Pronouns: they, them, theirs
Control System Applications Assistant
|
Beamline Controls and Data Acquisition, X-Ray Science Division, Advanced Photon Source
|