Number of Tag Change Scripts


Working on an old Modicon PLC. It has 23 devices attached and needs to monitor 52 registers for each device, doing math and writing to multiple database tables on changes. To further complicate it, half of the registers are 16 bit words that we need to monitor to the bit level.

My first instinct is to put tag change scripts on each register, but that would mean creating close to 1200 tag change scripts.

My next thought was to use transaction groups, but that still seems like a ton of groups.

Do you guys have any suggestions?



Hi Mike,

You may be able to use event.tagPath to help cut down on the amount of scripts.

A little more info in the manual:


I know it would really just be one script behind them all that would parse apart the path name, I just worry about the other effects that having over 1000 gateway scripts could have.

If I take it down to the bit level it would be about 5000 (not all of the 52 registers are used for their bits)

If there is only one script behind them all then why would there be 1000 gateway scripts?

To me it sounds like you only need to have one single Gateway Tag Change script.

A single tag change script can take a list of tag paths. When any of the tags change then the script is executed.

Make one tag change script, put all 1000 tag paths in the tag path list and have the script use event.tagPath to determine what to do.

Try it out (test) and see how well it works.

Note: A fast way to add many tags to the tag path list is to select many tags in the SQLTags Browser and drag and drop them into the tag list.

Excuse me.

1000 tags triggering a gateway script could have

Thanks for the advice. I’ll give it a shot and see what happens.


Yeah, you’ll want to make sure the script is sufficiently efficient in what it does, depending on how often the tags change, but the fact is, if you have a certain amount of work to do, doing it in this manner is about as good as it’s going to get. Having 1200 transaction groups would be very heavy. In this case, as mentioned, you just have 1 script with 1200 triggers. The triggering part is not really very intensive, so as long as the script isn’t super heavy, you should be ok.

In regards to the execution model, the script will only run for one tag a time. Multiple tag changes will queue up to run. So, the only real pitfall you’re trying to avoid is having events occur more quickly than the script can be executed. I suspect this won’t be a problem, but on small tip that might help would be to not break out the bits into different tags, but instead just examine them inside of the script. Doing multiple things in the script will be quicker than launching many executions of it.


Thanks Colby! That is exactly the type of advice I was looking for.

I hope you have a great day.

  • Mike