Our Ignition Vision system has tags defined that often contain several UDTs within their defined tag structures. Each item within the tag structure contains their own properties, one of which is "Tag Group." The system allows me to configure different tag groups, but does the underlying function of ignition allow different parts of a tag to get scanned at different rates? Or, does it simply default to the fastest defined rate of any item contained in the tag structure?
Thank you!
The Tag Group a tag is assigned to will be respected and is independent of any other tags in any UDT it may be a part of.
Now... if these tags in the UDT are all coming from the same structs in the same PLC... this is probably not what you want, performance-wise.
Yes, different polling rates to a single PLC tag often yield pathologically bad performance.
Yes, pretty much what I have assumed.
Thanks, Kevin.
Just a quick follow-up to let folks know how big of an issue this was causing. One of our AB Logix controllers was showing 3200+% overload (yes, 3200 - which certainly qualifies as pathologically bad) with actual sampling rates in the 22 second range. Suffice to say, operators have been frustrated.
After fixing tags so they didn't have sub-items with different defined tag groups within the same tag structure the overload has dropped to 150% with actual sampling rates around 2.9 seconds.
Yes, this still needs some work to improve it more, but this was a huge find.
OMG, I just discover some projects created by other guys used UDT, and different UDT belongs to different groups, and every group has different scan rates; further more, there are UDTs based on other UDTs (UDT nest in other UDTs).
pturmel:
Are you sure it will perform badly?
What kind of issue could it be?
Lucky, I double checked it, it is not my company's scheme. It belongs to other company's template.
All their UDT and tags are all built with different tag groups.
Wow!
Extremely likely.
Only OPC subscriptions that are at the exact same polling rate get optimized together. During optimization, leaf members of structures of the same tag are likely to be read together, even if some members between them are not polled at that rate. If the members between (and/or others in that tag) are polled at different rates, you can have multiple bulk reads of the same tag, for each rate. Where all of the tags could have been satisfied by one bulk read.
I encourage my clients to use a small number of subscription rates (can be many tag groups) and ensure that all elements of a top-level tag are assigned the same rate. Period, no exceptions. Redesign your PLC's data structures if necessary to achieve this.
pturmel:
Thank you very much.
It is really good to know this.
In my project, I basically have 2 tag groups, one is for regular use, the other is for history tag.
In the Trend folder, I create a tag called Flow_tag, it is assigned to History Group.
In the PLC folder, I have the same link to the same PLC tag, but assigned to a different group with different rate.
Would it also cause issues?
Similar, but not the same issue. In this case you would potentially be making more reads to the PLCs for the same tag. The other is making more reads to the PLCs for different tags.
I'm not sure why you would want to set up a single tag in this manner.
Yeah, avoid that. Just use one polling rate for any given tag. (Top level tag in the PLC.)
Thanks.
I would still like to have same tags in different folders, just make them the same rate.
It is easier to manage them when I have different folder for different functions.
Because import PLC tags is so easy, I'd rather make faceplates or popups parameters string based so it can point to the same folder, we have standard PLC UDT tags.
I've tested UDT parameter and string parameter, they almost have the same speed when open a pop up or faceplate.
Yes, this is generally fine. Two Ignition OPC tags pointing at the same OPC Item, at the same rate, doesn't make any extra PLC traffic. Just a tiny bit of extra book-keeping in Ignition's memory.
I just want to make sure I understand this, I know I am once again reviving an old post lol. Your recommendation is that UDT's in Ignition should mirror the UDT in the PLC and every tag be a part of the same scan class/tag group. Any attempt at making the individual tags of the UDT's part of a different scan class/tag group to "lighten" the load of the will not work and might make performance worse? We should use nested UDT's so that a UDT as a whole should be set to one tag group?
NO!
UDTs in Ignition should reflect the hierarchy required for efficient parameterization of views/windows/templates in your user interfaces. While you might be able to design your PLC's tag hierarchy for that purpose, too, it is unlikely in most cases.
Every Ignition OPC tag that points anywhere within a particular PLC top-level tag should have the same pace. No matter what UDTs or non-UDT tags are involved, and no matter what group names are used. Only the pace matters.
When dealing with PLCs that don't use named top-level tags, apply the rule to OPC items within the same PLC data block or within a contiguous range of raw addresses.
Generally not. Parts of a UDT optimized for visuals may have elements pointing at different parts of the PLC, with different paces required.
I appreciate the enthusiasm lol.
Let me digest the points you made and see if I have any other questions, but I think I am following what you are saying.
Old thread, but geesh. Thats a pretty important hidden nugget and new to me.
So i have many ignition UDTs that are for motor control. Standard PB for start, stop, amps, temperature and flow (process pumps). They point to a Logix UDT that has these elements contained within. I thought i was doing good by setting the temperature and flow to 5000 ms scan, while having the PBs at 500ms for faster HMI responsiveness. Now Im learning thats the exact opposite??
I understand the mechanics i guess of bundling reads/writes but that seems awful limiting. So the suggestion would be to create individual PB tags at one scan rate, the process tags at another scan rate. Seems to entirely defeat the benefit of creating a single UDT for organization. I dont pass UDTs anyway, only text paths to form my tags on popups, templates, etc, but redoing 6000 tags to divorce these UDTs in a current project would be a time consuming undertaking.
In monitoring the response on the system, my overload is 0% on all my tag rates between two devices, with mean response times in the 3 to 5ms rate.
So where else would I be seeing this if it were an issue? Because it doesnt seem to be and id hate to redo all of these tag structures for no reason.
Edit to add: In the case of Logix, if you divorce the boolean PBs outside of a UDT, you are using 32x memory. Logix stores all data types as 32bit. A single boolean takes 32 bits of data. Thats the benefit of UDTs in logix, as a UDT compacts all the data into consecutive bytes. So if i remove a boolean PB from a logix UDT as a singular tag, thats more memory traffic and more of a hit than servicing the UDT twice for different scan rates. For that reason, most logix developers either use UDTs or will use a DINT and use bits of that DINT for individual booleans. But Ignition doesn’t handle bit of words very gracefully without creating a UDT to form bits of words, so i dont know if thats anymore efficient either.
Uhm, no. That would be even worse, as individual tags cannot be optimized at all.
A few button booleans buried in another UDT is not really a problem. Just put them on the same subscription pace as the rest of the UDT.
Have you read this other topic?
Also:
Simply not true, for device drivers that can perform read-modify-write atomics, and Logix certainly does. The logix driver simply doesn't make drag and drop convenient for booleans in integers, but you can certainly append the .0 yourself.
Thanks for the link. Fortunately, most of those practices are followed in my development. However, in the case of UDT handling, i also did not realize that unused members are read in the packets and thrown away. This rabbit hole is getting deeper. For most logix developers, UDTs are functionally developed. They are packaged to support a process in an elegant and logical manner, making development and portability of code easier, easier to troubleshoot, eaiser to globally change code (add a needed member and it updates all instances). I've succesfully used this model with all manner of HMI and Scada development, with no comm issues at all.
Theres also the case that as integrators, code is portable across scadas. I have large code bases that are the same whether wonderware, factory talk, ifix, panelview, or ignition are the front end.
With Ignition, now I'm understanding that a single UDT that could be used before, needs to be split into three or more UDTs at the logix level?
A UDT for poll rate A tags
A UDT for poll rate B tags
A UDT for non needed Ignition tags
As a simplified example, a pump UDT tag that has start and stop PB, flow and temperature analog, Timers for alarm handling.
PBs in one UDT (fast poll), Temp and Flow in another UDT(slow), and Timers in a third UDT (not needed in Ignition).
Thats an over simplified model of course as UDTs contain more info, but that's what I'm gleaning from this conversation. While it may streamline the ignition driver performance, it sure doesn't seem conducive to standard Logix practices of development.
Yes, but it's Rockwell's implementation in the PLC that makes reading whole UDTs so much more efficient, not some choice we made in the driver.
These steps are only necessary if you are currently not able to meet your performance needs.