If I have two tag groups with the same rate fx. 4000 ms will they then execute at the same time?
Lets say that one executes at
12:00:00, 12:00:04, 12:00:08, 12:00:12 and so forth
Will the other also excute at those time points or could it have a different offset that makes it execute at other time points like
12:00:02, 12:00:06, 12:00:10, 12:00:14
So they execute with the same rate but at different times?
We currently have about 670,000 tags.
At the moment the tags are spread across roughly 40 tag groups with different rates and it is running fine, but I want to clean it up a bit. I’m just unsure how to break it up.
Is there a best practise for amount of tags in a tag group to minimize network load?
I mean if all of them were in the same tag group would Ignition then try to update them all at once with a large load on the network as a result?
Is it better to put tags from the same PLC in the same tag group or doesn’t it matter that a tag group updates multiple tags from different PLC’s?
Tag group rates are targets, not exact, and do not have precise start times. They run at the best effort pace of their contents. You cannot control the "offset". Look at individual device status pages to see how closely the device is achieving the paces requested.
Tags pointing at the same processor and same top-level tag will be optimized to be read together only if using the same pace. This is how you minimize network (and PLC) load. It doesn't matter if there are many tag groups--it matters if the pace differs.
Optimization is brand- and driver-specific. For modern Allen-Bradley, this discussion (and the links within) may be helpful:
Im not sure what processor and top-level tag is in this context?
You write that it doens't matter if I have many tag groups, but it matters that the pace differs. Does that mean that having many tag groups with the same pace essentially works the same as having all the tags in the same tag group?
Doesn't it have any effect to place tags from each PLC in their own tag group?
First Siemens experience was S5, a very long time ago. At the time, ladder support was minimal, and easy to break, so all code with critical performance requirements were statement list. Which is really a Domain Specific Assembly Language. Dealing with poorly documented statement list was cruel and unusual punishment for a young electrical engineer. And infuriating to the electricians and technicians around him. Ladder logic was created to allow non-engineers to work on and troubleshoot automation. Failing to use is where possible is a sin in my book.
I later learned that German technology training has a tier for such that explains the rampant, unnecessary use of statement list in automation, as a form of protectionism for that tier in the German labor market. Or so it was explained to me by a German engineer. I don’t care for protectionism in labor markets.
More recently, when investigating Siemens protocols for possible module development, I learned that:
Modern S7 optimized access via Ethernet is carefully protected technology, with extreme licensing and royalty terms.
Profibus is also effectively closed to affordable implementation by outsiders.
Profinet uses a custom Ethernet Layer 2 frame type, requiring branded switches and routers for full functionality. It also precludes reasonable implementation in java. Profinet’s meta-data exchange is also horribly complicated. Way more trouble than EtherNet/IP.
In summary, I started my career disliking Siemens technical choices. Then later I disliked their business practices. Today I find I’ve come back around to disliking their technical choices.
I also started myself, many years ago (hint: 80s), with the S5.
Siemens was my first PLC, and as it turned out 35 years later, also the only one I actively worked with …
It’s probably (not probably … IT IS) also my handicap to be biased.
Of course, I met other PLCs (Omron, Mitsubishi, Allen Bradley, …), but, as my colleague says,
altogether it’s one big piece of shit, but out of all this shit, Siemens is still the best in terms of support, documentation, …
At least in Europe.
Siemens PLC today is very good (let’s leave company policies aside).
Other things too (VFDs, Servos, … except WinCC SCADA , of course) are very good.
I don’t want to start any debate about what’s better and what’s not …
This is just a polite passing opinion between two veterans in Industrial Automation.
Guys I appreciate the attention you spare for my humble post, I really do, but do any of you have further advice for me regarding my issues with tag groups?
I’d really like to understand the difference between one tag group vs. multiple tag groups using the same rate? Like if I have 100000 tags in a tag group with the rate of 4000ms is that different than 10000 tags in 10 tag groups at rate 4000ms? Is it better to do one or the other?
And does it have any effect to have a tag group handling only to one PLC instead of multiple PLCs?
It is no better either way as far as Ignition's native drivers are concerned. They only look at the pace for optimization. They can't even see the separate tag groups. So tag groups are still useful for administering large installs, but not for optimizations.
It might be better to separate by OPC server when using OPC client connections to third party servers and/or PLCs w/ OPC support. Separate tag groups will make separate subscription groups--that can help mitigate the limitations of some OPC servers.
For an example if I have an OPC tag that out puts a 1 or 0, with a tag group Rate(ms) as 300,000 (5 minutes), and then a derived tag that uses a switch function to return a string for that memory tags output.
Is there a case where the derived tag will only up date with the tag's Tag group rate?
I was assuming it only deals with aspects of tags that have polling of some kind, but wanted to double check to be sure.
, of course) are very good.