I want to take a "snapshot" of tag values at a certain time each day and write the tag values to "snapshot tags". I have this working by using an "execute" tag that runs a script and copies the current values from the tags to the snapshot tags at certain time each day. My problem is that I will need to run 168 scripts at the same time to move all the tag values to the snapshot tags using my current configuration. Any thoughts on other approaches that may not be so Gateway intensive? It will be around 1000 tags.
Why? 168 doesn't seem like just any random number so where did it come from?
If you have the SQL Bridge Module then Transaction Groups can do this.
You could also use a Driven Tag Group for your Snapshot Tags, make them all reference tags, and then drive them off of a Trigger Tag that your script sets and resets, or just the System Time.
Honestly, a Driven Tag Group with a driving expression like:
if(getHour24(now(1000)) = 6 && getMinute(now(1000)) = 0 && getSecond(now(1000)) = 0,1,0)
is probably the best solution.
What's the purpose of the snapshots?
I'm testing with a UDT right now. There would be 168 instances of the UDT with the UDT having 6 tags. The tag values show different machine performance values and display on a perspective dashboard. The want is a snapshot of the final values shown on the dashboard at a certain time each day (time will change based on a table value). The dashboard would be modified to allow a view of the previous final tag values. I have a transaction group that is writing the snapshot tag values to a table right now, but only for my testing UDT.
This sounds like a job for Gateway Events - Scheduled Scripts.
Write a script to read all the tags at a scheduled time of day and insert them into a database rather than tags. This way you get predicatable behaviour with history thrown in for free. The latest values can be read out by query or by query tags.
Is using tag history not an option?
Not when you want precise counts at a particular time. I have always found the historian's compression and lack of proper interpolation and extrapolation to cause it to mis-report. You can't beat a defined recording.