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.