I'm kind of curious why i've been able to build HMIs for decades without worrying about ANY of this, but with Ignition it feels like setting up PLC comms is a minefield filled with flaming hoops you have to jump through to get everything talking efficiently. Like, if I'm making a C-More HMI program, or even a Panelview Plus, I've never had to worry if I'm looking at an Aliased tag or an AOI element before. Is there something fundamentally different with the way Ignition does things?
At the end of the day, customer wanted Ignition, so I'm going to make it work, but if I bring these concerns up with some of the higher-ups, they're going to be asking these questions, too.
Consider getting the "Logix Live Types JSON" from the device's extra "Configuration" page and sending it to my support email. That "live" export includes some metadata that indicates where the driver is encountering unreadable UDT or AOI members.
Unfortunately, some built-in instructions in Logix firmware have associated data types that aren't completely readable. And most I/O module data types have this problem, too. Where you encounter these, some UDTs that mimic the byte layout can be used in a read-only but optimizable fashion. (Some CPS instructions in the ladder, and point Ignition at the copies.)
IA has a non-reverse engineering policy. I do not, making my driver run faster where that matters.
Most simple HMIs (I happen to really like the C-More family) will only poll the tags that are currently displayed. Ignition polls everything that isn't leased.
You've probably never been able to so easily create so many tags. You don't have 20, 30, 40k + tags with lots of these other HMIs.
The other is that sometimes these companies have old deals where they use comms drivers or software from Rockwell, or you're dealing with Rockwell software itself. They use proprietary access methods and do not publicly document it for the rest of us.
I set my leased tag groups to poll at 0ms base, 1000ms fast, and 2500ms standard.
This dropped the overload on that connection to 0% most of the time. The PLC utilization peaks in the high 90%s but doesn't stay there. It bounces between 30% and 99%.
This is all on the standard driver. I haven't tried these new settings on Phil's driver.
I think the ultimate solution in the short-term will be to just accept I can't poll tags that fast. At this point, I think I can live with that.
In the meantime, I will still look into how I can optimize my tag mappings, looking at base tags instead of aliases, making sure I'm not directly addressing any AOis, etc.
From a development perspective, the way Ignition lets you create UDTs and tags is unparalleled and I do like that. I see your point about being able to create this many tags, too.
As far as proprietary access methods...that's not surprising.
Our driver uses what is made public in 1756-pm020. Phil uses this information + has reverse engineered the AOI format.
FactoryTalk Linx not only understands AOIs but has an entirely separate undocumented mechanism for reading tags, something you see references to here and there as "Optimized Packets".
So, when I set up a leased tag group to 0ms rate and, say a 1000ms leased rate, does that effectively make it behave like a C-More/PVPlus/whatever HMI?
I know there are exceptions, like if an expression tag references it, it leases it too, but I don't have a lot of that going on.
Yes. But note that 8-second switchover in pathological situations can bite you.
Also, if you have members of UDTs or AOIs that are being read at the 1000ms pace, and other members of those same UDTs or AOIs being read at the 2500ms pace, you are screwing up. The entire UDT is likely being requested at both paces, wasting bandwidth.
If you have some members always being polled at 1000ms, and other members in the same structures leased, you might as well make them unleased.
Among your assigned reading above is a discussion of segregating PLC tags by desired polling pace so that stuff that is polled together is optimized together.
FWIW, Rockwell's Logix processors are the best I've seen in total tag scan capacity, measured in bytes of raw tag data per second, as long as it is organized for optimization.
That might help, but you're missing the important part of what he's saying.
If you have a UDT with members A, B, C, and D, and A+B get leased @ 1000ms, but C+D remain @ 2500ms, then you are now reading the whole UDT at both rates.
Both the IA and Phil's driver read whole UDTs whenever possible because it's the highest performance, but that means you are responsible for ensuring that:
all the stuff you need to poll from Ignition is nicely concentrated in UDTs
you poll tags belonging to the same UDT at the same rate
You kind of lose some control over this with leasing unless your UDTs are all-or-nothing when they get leased.
I'm saying if I set the lease rates for both at 1000ms, then I'd be reading both A+B and C+D at 1000ms, right? Would that at least give me an indicator of something?
Well, any of A, B, C and D belonging to a different Tag Group than the other members should never be done, so they are all going to implicitly have the same leased rate unless you've split them into separate groups for some reason.
Traditional driver: 17% overload consistent (it always says overload but the number only turns red when it's over 100%, so is 17% fairly normal, or is 0% overload my goal?)
This. Anything more than an occasional small overload (~1-3%) is a problem to be fixed.
IA's driver gives you no indication in its stats how much leeway you have, because it spreads the requests over the entire polling period. My driver goes as fast as it can per period, so you can see in its diagnostics tags how much of the period it really uses.
It's the same module for all three driver types. The Class 1 functionality is part of the "Host Device" driver type, and part of that functionality is in the "Target Device" driver type.