Message packing on OmronNJ/NX beyond max response size

[ptsOSL]

I have been encountering a problem with packing of CIP requests when reading data from OmronNJ. libplctag is packing many read requests into a single request message, as I have requested. However, if the size of the response packet (the size of all of the data which is being read) is beyond the max packet size of 1996 bytes, then I receive error 0x1B, routing failure (response packet too large). This is mostly a problem when packing multiple large structures together. I am guessing this is only a problem on Omron as it does not support fragmented reads. Looking through the source code, I didn't see anywhere that libplctag checks to see if the combined size of the response message would fit in a single response packet, but i might have missed it? Would it make sense to individually read each item that is to be packed when the tags are initialized to see if they can be packed together? This is something the user can do, however it seems more like something libplctag should do, but I might be misunderstanding something. Cheers

[kyle-github]

I don't have an Omron, so take what I say with a grain of salt. From what I understand, Omron decided to behave differently than Rockwell in some key areas:

• packet size negotiation works, but only up to about 1900 bytes.
• When retrieving a tag, the count seems to be ignored and (possibly?) may be refused if it is not 1.
• When retrieving an array tag, the entire tag is returned instead of just the requested elements (this was reported but I cannot verify).
• There is a limit on the size of the returned data. I think it is around 256 or 512 bytes. Anything larger than that seems to fail.
• There are additional CIP commands that Omron uses to get arrays (or array elements?) that are larger than the above limit.
• Omron does NOT support the 0x06 status code which means "partial result" for Rockwell. Rockwell uses this to return partial results and then uses the offset field in the request to get the next chunk of data.

One of the results of all this is that you can request several tags at once, but if the results do not fit into the 1900 byte result packet, the whole bundled request seems to fail. I think this is what you are hitting.

So while Omron is using CIP it is not using the Rockwell commands. Unfortunately, I have not found a good source of documentation for Omron on this. There is a Python library that supports Omron with CIP that could be a source of ideas.

[ptsOSL]

So I have been developing with libplctag for OmronNJ for a few months now and some of the behaviour you describe differs to what I have seen on my Omron NJ:

• I believe the maximum packet size is 1996, its certainly around that number anyway, it is not actually specified in the manual
• The count tag is not ignored and I can successfully retrieve a slice of an array as long as the size is less than the maximum packet size. The library/plc seem to work well here and it is quite performant.
• This is only the case if you do not specify an index to the array, eg array[2], if you specify an index it will return the correct element
• I haven't seen this issue but maybe Im misunderstanding? I have read individual structured data >1000 bytes in size. I can also read slices of arrays up to the maximum packet size.
• There are, but I have not used them
• Yes you are correct on the 0x06 status code not being supported, this is what is causing problems with request packing in certain situations.

Yes this is my problem, I suppose this issue is about whether it would be a good idea to add checks to libplctag to stop users breaching this limit? Before packing requests together, the library could add up the size of each reads response data and only pack requests if their response data will fit in a single packet. Of course the library would have to do an initial read for each request to find out the sizes, but in the long run it would improve compatibility with PLCs which dont support fragmented reads and give better performance.

This is the manual I have been using