I have a similar setup and the best I came up with is exporting the transaction group’s XML, doing a find / replace based on your different instance names / tag locations, and importing the modified XML. Be careful on the path of the transaction group because it will overwrite existing ones without any warning.
You mentioned storing data every minute and transaction groups are good for scheduling something like that. But if you’re making extensive use of UDTs and can come up with a way to do your data collection through a tag event script then that script would work for every instance and eliminate the need for additional transaction groups per instance.
Thanks for the input @scicco, you have me contemplating both of those options. I found another thread discussing dynamically creating transactions groups. I’ve been thinking my way through using a script to modify an XML template and using system.groups.loadFromFile. But, I haven’t sold myself on this yet. Keeping track of when to add (possibly remove) transactions groups seems too complicated.
I think I’m leaning toward using the tag event script. My thought is to have a new ‘update’ tag that is on the PLC. If it is simply a bit that switches between a 1 and a 0 I could have tag event script run when the value changes from either 0 to 1 and/or 1 to 0. I’ll just have to write the SQL statements myself which shouldn’t be too big of deal.
If you need to keep some kind of scheduler in addition to an update that’s driven from the PLC you could also have a “Minute” expression tag as a property of your UDT whose value is the current minute. In the value changed event of that tag you could have a bunch of if statements that check the modulus of the new value by each desired interval to equal 0. The code could get a little messy but it is flexible.