# Dynamic Driven Tag Pathing? **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [November 3, 2023, 3:45pm UTC](https://forum.inductiveautomation.com/t/dynamic-driven-tag-pathing/81469 "2023-11-03T15:45:38Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Alex\_Fabiano](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@Alex\_Fabiano](https://forum.inductiveautomation.com/u/Alex_Fabiano)\ **Post date:** [November 3, 2023, 3:45pm UTC](https://forum.inductiveautomation.com/t/dynamic-driven-tag-pathing/81469/1 "2023-11-03T15:45:38Z")
Good morning In our plant 8, we have many cells, that are all monitoring many output string tags so we can store faults' output strings that occur in a fault history database. The problem is, monitoring this many tags is quite heavy on the system, and leaving them all at one rate means that every hour, or two hours, or however long we decide to wait between scans, all the tags will try to read at once, severely slowing down our gateway. (We are still monitoring the faults themselves at 1 second, the output strings don't change too often though, so we can slow down their monitor rate.) I am looking for a way to make it so I can use just one driven tag group for multiple cells, but it doesn't seem like that is possible. Is there some efficient way I can say "At this time, for the next 3 minutes, cell 8W001 has exclusive permission to update its output string tags." and then "Now at this time, 8W027 has permission to update its output string tags." and so on. So far, the best way to go about this seems to be having a folder with different booleans that turn true at certain times of the day and creating a tag group for every cell. I was just wondering if there was a more efficient way to do this? A snippet of the tag browser: ![CMM Tag Groups](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/4/34609f6fe815a51f4ed14d43c27ad209f95d65b1.png) A picture of our scan class: ![No Dynamic](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/0/001f8b176cca95218c898972a9f892be54999b5d.png) An idea of the faults names we want to monitor: ![Dynamic Faults](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/e/ce41d7ec411e5ac5603a078c98c8d732a8a4e50f.png) Some cells can have 12000+ unique dynamic zone faults: ![zoneflt](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/1/b16c42906006c308e89533a22d5859cc8a0c71b3.png) Thank you for your time and any help is appreciated. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [November 3, 2023, 4:28pm UTC](https://forum.inductiveautomation.com/t/dynamic-driven-tag-pathing/81469/2 "2023-11-03T16:28:46Z")
I'm somewhat skeptical of the performance problem here being the _gateway_, unless it's severely under provisioned, but taking it at face value... You could just not have tags for these fault codes. Instead do a dynamic read ([`system.opc.readValue`](https://docs.inductiveautomation.com/display/DOC81/system.opc.readValue)) every time a fault happens. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [November 3, 2023, 8:38pm UTC](https://forum.inductiveautomation.com/t/dynamic-driven-tag-pathing/81469/3 "2023-11-03T20:38:24Z")
I'm curious how many total tags you have? > [@Ignition Tag Count in a project](https://forum.inductiveautomation.com/t/ignition-tag-count-in-a-project/78201/2): > > This will give you the total number of Ignition tags in a tag provider, and summarise them by different properties. Run this in the script console, preferably directly on the GW server. """ Produces a summary of tags. Example output: Tag summary ======================== tagType: {'UdtInstance': 43, 'Folder': 95, 'AtomicTag': 644} valueSource: {'memory': 197, 'opc': 391, 'reference': 1, 'expr': 47, 'derived': 2, 'db': 6} dataType: {'Float4': 2, 'Int2': 3, 'DataSet': 43, 'Float8': 18, 'Int4': 2… ---
**Author:** ![Alex\_Fabiano](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@Alex\_Fabiano](https://forum.inductiveautomation.com/u/Alex_Fabiano)\ **Post date:** [November 3, 2023, 9:47pm UTC](https://forum.inductiveautomation.com/t/dynamic-driven-tag-pathing/81469/4 "2023-11-03T21:47:39Z")
# Tag summary tagType: {'UdtInstance': 2571, 'Folder': 8393, 'AtomicTag': 525000} valueSource: {'memory': 15348, 'opc': 502372, 'expr': 7260, 'db': 20} dataType: {'DataSet': 8634, 'Int4': 4122, 'Int1Array': 125346, 'Int4Array': 20250, 'String': 356045, 'DateTime': 10, 'Boolean': 10593} tagGroup: {'Default': 76016, '1sec': 138828, 'ZoneFltV2': 321000, 'QueryFaults': 120} eventScripts: {'eventScripts': 8678} historyEnabled: {'False': 535964} ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [November 3, 2023, 9:52pm UTC](https://forum.inductiveautomation.com/t/dynamic-driven-tag-pathing/81469/5 "2023-11-03T21:52:22Z")
> [@Alex\_Fabiano](#): > > 'opc': 502372, That's quite a few. I should probably add a summary per PLC device as well, but how many tags have you got per plc? And what do the stats look like for your plcs? (gateway page, status, devices, click on a plc, look at the overload) Also, what are the specs of your server? (cpu, ram), is it running in a VM? If so, are the resources dedicated? Have you read this doco? > **[Ignition Server Sizing and Architecture Guide](https://inductiveautomation.com/resources/article/ignition-server-sizing-and-architecture-guide)** > > This guide is intended to provide some tips to help you determine the correct architecture depending on your requirements. It is important to note that any architecture that you come up with needs to be fully tested and verified. Throughout that...