In Ignition, I have multiple tag groups with different sample rates. Most of my tags are polled at the slowest rate through a leased group. Ignition indicates around 222 requests a second overall, and around 103/s for the slowest group. Based on that, I would think that all 1025 requests in the slowest sampling group would be spaced out along the total sampling interval.
However, when monitoring the Class 3 utilization rate on the L81E PLC, it swings from 15% all the way to 98%. The frequency at which hits the 98% is directly proportional to the sampling interval of the slowest and largest tag group. I would think, that everything else being the same, the Class 3 utilization rate would stay pretty consistent if Ignition was spacing out the requests along the whole sampling period. In actuality, is Ignition sending all the requests for a sampling period at the beginning of the period and then waiting until the beginning of the next period to poll again?
Is there anything I can do to reduce the utilization rate on the PLC besides reducing the total request count? For instance, would creating more tag groups with different periods distribute the load on the PLC more evenly?
No, generally not. When it is time to do a particular poll, the messages are queued up.
What you are seeing is normal.
Leased groups are not as helpful as you might think if the leasing situation has parts of tags in both paces. Optimization is based on top level tags (controller tags and program tags). If leasing targets a specific top-level tag in more than one pace, you can actually increase the message load.
Have you seen this topic (and the ones linked within) ?
Thanks for the quick response. I have seen that topic and I am using UDT's with all members of each UDT only belonging to a specific tag group. I will experiment with additional tag groups at different rates and see if that helps smooth it out a bit.
That's likely to make things worse. Any given top level tag should be accessed with one pace. (At least, any substantial consecutive block of bytes.) It is very hard to make this happen with leased tags or multiple tag groups.
So Phil, I've got a question regarding this optimization. If I create a top level UDT (lets say "Motor") and nested inside that UDT are other UDTs like "Cmd", "Sts", "Cfg", etc with various tags in each, would it still be optimized if all the Cmd tags poll at one rate, Sts tags at a faster rate, and Cfg tags at a 3rd different rate? I realize having them all poll at a single rate is more efficient, but when you get to thousands of top level tags, would it be more efficient to break them up and have the nested UDTs break out at the different polling rates, or still better to leave them all at one rate?
for our driver, at least, the answer is a big fat "it depends". Mostly on the UDT size and size of sub-UDTs.
You'd have to just try it and see on a separate driver connection where you experiment and look at the diagnostics to see the total request count.
edit: eh, total request count might not even be enough. Might have to look at Wireshark too. The real question is whether the request for each rate ends up targeting a sub-UDT, or ends up targeting the parent UDT.
No. They'll each get their own smaller, low-level request instead one larger low-level request. Low-level requests get assembled into buffer-sized "multiple request" packets, so the impact on number of requests in the diagnostics might not be obvious. But class 3 message processing in the PLC is much more affected by number of low level requests than by the total size of those requests.
But for best possible performance, create an array of your Motor UDTs. Make aliases in your PLC if you need to continue using the original names, but access the array elements from Ignition, entirely at one pace. Class 3 Msg load will go way down.
Maybe if I ever get to do a new Logix driver... there's a handful of improvements I'd like to make, including taking a stab at AOI support, though it would be opt-in via configuration.
So all the Sts members would be in a low-level request (let's say on a Direct 1 sec group), all the Cfg members would be in their own low-level request (perhaps leased 5 second group), etc. As normally my Sts tags are direct polled, but I don't really need the Cfg or Cmd tags unless the faceplate is pulled up at which point they need polled, but not even that fast, so wouldn't have to be faster polling.
I get what you're saying about the arrays, but would definitely take more planning ahead and making the arrays with some spares for growth so that online changes can be made, although for end customers I don't know if the added complexity of it is worth the trade-off in reduced load if we're not having comms issues. Definitely food for thought. Thanks for the insight.
Consider breaking up your Motor UDT. An array of Sts members could be polled directly, separately from Cfg or Cmd.
This is one of the things AOIs are good at--using InOut structure parameters that point at specific subscripts of an array of those structures. The logic in AOI doesn't care where they really are, and Ignition (or any other SCADA) gets to optimize the arrays.
(Of course, if you use my driver, you can keep all of the Sts right in the AOI, putting just the slower/optional stuff in an InOut parameter. But do make the AOI data itself an array.)
That's how I use it currently. I have the motor AOI, and a motor UDT, and pass the motor UDT to the motor AOI as an InOut parameter so that comms can be optimized. I guess this could be taken a step further and break them out into separate UDTs (they technically already are because they're just nested UDTs inside the motor UDT), but could then pass them individually as array elements of each to the motor UDT.
I'd really want to use your driver, but I'm working on several Edge projects for OEM stuff right now that I have to make work with the built-in driver. (Plus trying to make standardized UDTs, graphics, etc that can be used on any project - Edge or Standard so that it's more efficient from a design perspective to build out projects quickly)
On your AOIs, even in an array, are they just as fast as UDTs as long as all internal/local tags and parameters are at least ReadOnly for external access?
It actually improved a bit with an extra group, but as I added more groups at different periods, the total request count went up and the performance went down. The improvement was maybe 10%.
What has given me the best improvement, is going back to two sample rates, but making sure that they aren't multiples of one another. It impacted the performance of Ignition a bit (slightly overloaded), but my Class 3 utilization peaks around 74% and averages around 50%.
You're living in a fantasy world if you think a 10267ms group is any different than a 10000ms group.
Scheduling of requests simply does not work in a manner that people who come up with all of these crazy prime numbered non-overlapping schemes think they work.
You're probably right, but I can't argue with the numbers. I was at 98% Class 3 utilization and now I'm at 74%. Logically, it makes sense if they're both not polling the PLC at the same time.
Actually, you are most assuredly right. I had stepped away for a meeting and had forgotten that I changed the Max Concurrent Requests from 2 to 1 right before I left. That's what brought my Class 3 utilization down. Changing the multiples of the sample rate had a negligible (if any) impact. Thanks for the help.
