Lowering the EIP buffer limit from 500 to 480 has alleviated the problem! Now all tags can be loaded by the IOC, and the alarm state (and associated display elements
on MEDM screens) render correctly.
Pursuing the errors with the buffer limit set to 500:
It appears that the error is not related to the specific set of gate valve tags; in my last experiment, I included only analog input records (records holding
date and time information). I found that the maximum amount of these analog records I can include is 256; when I include one more for a total of 257, I get a similar error as before, except this time the CIP_MultiRequest reply is 0x1E:
2020/01/16 12:04:21.2446 EIP process_ScanList: Error in response
Tag 0: 'Faults.Number'
Tag 1: 'Faults.Year'
Tag 2: 'Faults.Month'
Tag 3: 'Faults.Day'
Tag 4: 'Faults.Hour'
Tag 5: 'Faults.Minute'
Tag 6: 'Faults.Second'
Tag 7: 'Trips.Number'
Tag 8: 'Trips.Year'
Tag 9: 'Trips.Month'
Tag 10: 'Trips.Day'
Tag 11: 'Trips.Hour'
Tag 12: 'Trips.Minute'
Tag 13: 'Trips.Second'
Tag 14: 'Warnings.Number'
Tag 15: 'Warnings.Year'
Tag 16: 'Warnings.Month'
Tag 17: 'Warnings.Day'
CIP_MultiRequest reply: general status 0x1E (One of the MultiRequests failed)
18 subreplies:
0) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
1) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
2) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
3) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
4) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
5) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
6) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
7) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
8) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
9) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
10) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
11) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
12) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
13) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
14) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
15) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
16) service 0xCC (CIP_ReadData-Reply), status 0x00 (Ok)
17) service 0xCC (CIP_ReadData-Reply), status 0x06 (Buffer too small, partial data only)
2020/01/16 12:04:21.2449 EIP disconnecting bleps
Thanks for the helpful explanation of the communication parsing of the tags as related to network traffic and efficiency, and it makes sense; I will take these
guidelines into consideration.
Best,
Roy
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
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 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