Seems strange.
> 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:
MultiRequest (0x0A):
ReadData(0x4C) 'tag 1'
ReadData(0x4C) 'tag 2'
ReadData(0x4C) 'tag 3'
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.
-Kay
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
|