I'm reaching out to the community for insights on setting up tag groups in Ignition. Below, I've detailed our journey, the challenges we faced, and the solutions we implemented. I hope this context will help you understand our current setup.
Background:
- Initially, we utilized a single tag groups named "default" for our extensive Ignition project.
- We encountered performance issues.
- Modifying the tag groups polling speed alleviated some problems but was affecting the entire site.
- Our configuration involved a PLC reading/writing to OPC tags, which powered our displays and pages.
First Improvement:
- We assigned each project PLC its distinct tag groups. This allowed us to tailor performance to the application without influencing other project segments. Additionally, during off-seasons, we could inhibit tags, alarms and stop filling the historian, thereby reducing overhead.
Second Improvement:
To enhance performance, clarity, flexibility, and development time, we:
- Shifted to driving our displays/pages off reference tags. Instead of relying solely on OPC tags from the PLC, we established our reference tags and mapped them to the OPC tags once the code was finalized. This strategy facilitated structured tag development and enabled concurrent Ignition project and code development.
- This shift led to questions about tag groups, OPC tags, and reference tags. We were wary of potential missed changing values if both OPC and Reference tags shared the same tag groups. We hypothesized that reference tags might require double the polling speed of OPC tag. Consequently, we ended up with separate groupsfor OPC and reference tags.
Final Improvement:
- Recognizing that different tags required varied speeds, we further categorized the tag groups. For instance, historical trending tags might need updates every second, while parameters might only require updates every 20 seconds. This led to categories like:
- ProcessingLine1_OPC slow
- ProcessingLine1_OPC fast
- ProcessingLine1_Reference slow
- ProcessingLine1_Reference fast
This system has been effective for us. However, as our site integrates more with Ignition, the number of tag groups has proliferated, which seems excessive for our project's scale. Despite this, the setup is efficient post-initial configuration.
Here is a basic example of what we are doing
Discussion Points:
Engaging with colleagues has revealed both advantages and disadvantages to our approaches. However, we're still uncertain about the optimal method. Our primary concern revolves around the impact of the reference tag polling rate in comparison to the OPC polling rate. Specifically:
- Should reference tags poll faster than origin tags?
- If OPC tags poll at a 2-second interval and reference tags at the same rate, could we overlook some data?
- If OPC tags poll at a 2-second interval and reference tags at the same rate, Would this potentially lead to a response time of up to 4 seconds?
I genuinely hope this overview is clear. I'm more than willing to provide more diagrams for further clarity. We're eager to gain insights, so tech-savvy experts, please share your knowledge!
Reference tags don’t poll. The rate of the Tag Group they are in is irrelevant.
“Tag Driver” isn’t a thing, and I can’t figure out if you mean Tag Group or Tag Provider, can you clarify?
4 Likes
Wow.
A terrible misspoken term from my end, I apologize (and have corrected the post).
I did indeed mean tag group.
I think you have understood and answered my question brilliantly. But to to hit it home, what happens in this situation, when I change the tag group the reference tag is assigned to? Nothing?
Assuming my OPC Tag is set to poll at 1 second and I change the reference tag to say... a 20 second tag group?
Shouldn't make any difference for reference tags, they don't poll their reference, they subscribe/listen for updates.
Wish.... I had known that sooner!
Thank you so much for the answer - you have made the obscure crystal clear!
When you say performance issues, can you be more specific? Were tag updates simply slower? (writing to tags from clients visibly delayed, etc)
What plcs are you talking to, and if AB, what firmwares?
So many questions for a Monday!
If you see some of my other posts you will see details of my issues with performance with AB.
We have maybe two dozen PLC's and well over a hundred thousand tags in our ignition system, but our biggest project at the time gave us issues with ignition being at 650% load and the PLC being maxed out at 99% for MSG class 3 instructions. With approximately 7000 tags. (L82 processor)
We pulled lots of levers for improving our systems performance and followed a lot of advice on here also, but the only thing we hadn't tried at the time was playing with the polling rates, but a change to one system affected them our entire ignition project, which is annoying.
However a change of 100ms made a monumental difference to the problematic system - so it is something we would like to keep open in future.
The main reason for moving to separate tag groups was two fold. One to give us the flexibility to tweak this performance incase we had a plc that was getting smashed. Second it allows us just to shutter large parts of a project for the off season (our whole plant is seasonal - so 3 months here, 3 months there) - so we can just turn it off and reduce overheads.
Using our newest methodology we recently rolled out another project on an L73 processor, with even more tags and everything is humming along nicely.
I still have one last thing to try which is the class one driver released by pturmel. I think that is going to be a big win for us also. (https://www.automation-pros.com/modulesales.html)
Firmwares for the AB I think are all 32.... is not sure of the minor revisions.
I would recommend you give Phil's ethernet ip driver a go Automation Professionals' EtherNet/IP Communication Suite V2 - #108 by pturmel
He has seen 15x better performance when reading AOI tags directly compared to the IA driver. It's a direct drop in replacement for IAs driver and honours the demo period. What you need to ensure however in your plc programmes, is that all members of the AOIs and udts you're reading are set to at least read external access. You can do this easily if you export to an l5k.
It the same driver module. Just different features. The new stuff is the class 3 driver that is a a drop-in replacement for the IA Logix driver and/or Omron NJ/NX driver.
The older parts of the driver are various aspects of class 1 I/O and producer/consumer tag technology. Class 1 comms are blistering fast, putting much less load on the PLC, but require substantial PLC code re-arrangements to use. And, sometimes, major architectural changes to the application.
I know (and am happy that) many are enamored of the speed boost my class 3 client can provide for little engineering effort, but the class 1 adapter and scanner are the real speed demons.
2 Likes
