Large UDTs with multiple scan classes in a Rockwell PLC

I have been told that there was an issue with large UDTs with several scan classes when interfacing with a Rockwell controller. Where the PLC has a single UDT, and Ignition tries to pull the tags at different scan classes.

So if my PLC UDT has 100 tags in it; and my Ignition UDT scans 20 of the tags in a 1 second scan class, 20 of the tags in a 10 second scan class, and doesn’t scan the remaining 60 tags from the PLC UDT.
How will ignition scan this?

When it scans the 20 1 second tags, will it pull just the 20 tags? or will it pull the whole ignition UDT (40 tags), or will it pull the whole PLC UDT of 100 tags?

This could be an issue with the PLC, but I would like to know if anyone knows of a similar issue, or could confirm the above issue.

1 Like

You could capture traffic with wireshark for a definitive answer, but yes, you will have fragmented reads. In this situation, the best performance will be obtained when the various parts of the UDT that are in the same scan class are also adjacent in the PLC’s UDT.

1 Like

We have a similar situation and it has been difficult to get clarity on how exactly these requests will be made. There are a number of suggestions on optimizing scan classes and UDT usage in other posts. However, bringing it all together into a list of best practices for different scenarios I have not found. (If anyone knows of a good summary I would love to read it) It’s rumored that UDT reads may be optimized in the next major release, until then I have found much better performance can be achieve in using Kepware or RSLinx as the OPC server (with a lot less work) when connecting with Control Logix PLC or Safety PLC. The Ignition OPC driver can overwhelm the device pretty quickly if a lot of attention isn’t paid to optimizing every tag read. The device often seems to take the blame, but we’ve been able to demonstrate success with high scan rates and large number of tags by simply replacing the built in OPC UA server.

There was a regression on the Logix driver’s request optimizer that is fixed for 7.9.12.

With that fixed, you should find the performance to be more or less equivalent to Kepware but neither will perform as well as RSLinx because it uses some proprietary CIP services (“optimized packets” or “tag links”) that Rockwell refuses to provide documentation on.

I found the “Rockwell data access manual” to be the most helpful. It goes into a lot of detail about the CIP services, which is helpful if you are using wireshark to monitor communications, but it also has a best practices section which has a few suggestions on how to best access tag values from the PLC.

Thanks ibrandstetter, quick link for refenece: https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm020_-en-p.pdf

1 Like