We have a small project with a big tag count. We’re using Rockwell’s PlantPAx objects in a 1768-L43. The PlantPAx UDTs are huge and we have 12,000 tags.
The PLC is at 95% CPU, and 80%+ is communications.
I’m wondering if others have similar experience, and this performance and throughput is normal.
I’m not an expert on CIP, but it seems that polling each element of the UDT individually is very inefficient. One thing I’m wondering about is if the kepware or other driver is more efficient.
The UDTs are read as a whole when possible. The most common reason this isn't possible is when one or more tags in the UDT are not externally accessible. If you're certain tags are being read individually in the first place then that would be a good first place to look.
edit: also, what firmware version are you using and which Logix driver (legacy or new one)?
I only assumed that the elements were being read individually, based on the fact that each element gets its own address. What do you mean by “not externally accessible”?
The “External Access” property each tag has in Studio 5000. None, Read, or Read/Write. It’s a normally visible column when looking at tags in the regular view but hidden by default when looking at the definition of AOIs, I think.
Somewhere in 20.xx line they just up and yanked support for direct memory access, rendering the legacy driver unusable. 20.11 is the last version I know of that works.
Rockwell broke legacy driver support in v20. They have a few products, notably the CompactLogix L4x w/ motion & safety, that don’t have any v21+ alternatives. So they apparently butchered the very latest v20 firmware to have the new security restrictions (that prohibit direct memory access used by the legacy driver).
Thanks to all for the engagement here. I believe, but am not certain that I’m polling each element of the UDTs separately. There are not that many UDTs defined for the tag counts we are seeing.
How do I go about forcing the UDTs to be read in one request?
It will happen automatically, but only if every tag in the UDT is externally accessible.
The tag count will always reflect the number of individual tags you're subscribed to, whether or not they're read individually or a part of the whole UDT behind the scenes.
Look at the device diagnostics page to see the difference between the number of tags in a scan class for a device and the resulting number of requests needed to satisfy that scan class.
@Kevin.Herron I did the test and received no errors. I’m inferring that an error would mean that UDT’s could not be read as a whole and then would be read an element at a time. So this is not happening here. Correct?
If I’m interpreting @pturmel’s comment correctly, 6060 tags are being read with 401 requests. Which also implies that UDTs are being read as a single unit. Correct?
The issue remains that the PLC is swamped with comms requests.
PLC with device disabled.
When we were under the impression that elements were being read individually, we did a few things in an attempt to improve performance.
First, we removed any elements from the UDT that we did not need to display or historize. Based on my new understanding, this would not have any effect. Is that correct?
Second, we packed status bits into integers, again thinking fewer elements meant fewer transactions. Again the actual effect of this is probably negligible.
Lastly, we put elements that didn’t change often, such as configuration parameters in different, slower scan classes. Would this actually make performance worse, if those elements are now being polled separately?
The current situation is that we are trying to get 213 UDTs from the PLC at a rate of 1.5 seconds, and the PLC is not able to deliver this.
Consider raising the maximum request size in your driver’s advanced settings. Somewhere between 2000 and 4000 has been found to work well. Native Logix messaging with “Large Connections” uses 4002 bytes, fwiw.
If you still can’t get the performance you need, switching to the Ethernet/IP I/O protocol may make the difference. Your timing is good, as I have just completed release testing for my Ethernet/IP Class 1 Communications Module. Preview the module documentation here.
For those already interested in this module, you might be amused to hear that adding support for jython events kicked me in the tail through the summer. /-:
6060 tags in 401 requests, yes, but you can't infer anything about UDTs being read from that. The lack of the debug message does point towards it though.
That being said, there was a bug fix in 7.9.4 related to UDTs and optimization, so if you're not already on 7.9.4 you might see a performance increase by upgrading.
For the most part, yes. Unless you're talking about removing them from the UDT in the controller, in which case making it smaller is always better. There's a practical limit to this, of course: the driver won't read the whole UDT if you're only subscribed to e.g. 1 tag out of 20. If you're not subscribed to all the tags in the UDT it tries to figure out whether it would be better to read the whole thing or just the individual tags.
If they're part of a UDT that has other parts being read faster... yeah, it could be worse, if each group had enough tags in it to make the entire UDT be read.
The first thing to do right now would be upgrade to 7.9.4 if you haven't already. From there, if these controllers support firmware v21 or higher, that would probably help as well.
Try playing around with the CPU Time Slice % in the Contrologix. We use a stripped down versions of the PlantPAX templates and we had one project where 1000s of tags were read from a Compactlogix and response time was around 3 seconds when a button was pressed on the Ignition Mimic screens. Upping the CPU time slice to 50% reduced response time of a button press to less than 1 second
Hello!
PlantPAX PLC structure is recommended to be implemented such that there is no continuous task i.e. periodic tasks only… if this is the case, then changing the timeslice parameter may not improve PLC response time. However, its common to change this parameter from the default 10% up to 45/50%…more than that starts to deteriorate performace.
Here’s a link that explains this topic in a bit more detail. Cheers!
