# Counting uptime techniques **URL:** \ **Category:** Ignition\ **Created:** [January 25, 2023, 4:11pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012 "2023-01-25T16:11:31Z")\ **Posts on this page:** 16\ **Page:** 2
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [January 26, 2023, 7:36pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/21 "2023-01-26T19:36:01Z")
I don't know if it is a lingering concern from an old bug that people are concerned about. ---
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [January 26, 2023, 7:37pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/22 "2023-01-26T19:37:21Z")
I think you didn't read the post before the dashed line. That tag is being historized, and I tried to explain my question was more implementation side less historian side. ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [January 26, 2023, 7:37pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/23 "2023-01-26T19:37:31Z")
> [@zacharyw.larson](#): > > that the time updates will negatively impact the servos. From experience, it can, if you are using CIP motion, and the servos are in motion at the time. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 26, 2023, 7:40pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/24 "2023-01-26T19:40:15Z")
> [@JordanCClark](#): > > From experience, it can Indeed. Which is why everyone who can should be using a technology that eliminates the need to **ever** have to set the PLC time. ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [January 26, 2023, 7:40pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/25 "2023-01-26T19:40:59Z")
> [@JordanCClark](#): > > From experience, it can, if you are using CIP motion, and the servos are in motion at the time. To iterate, that is if there is a large swing in time difference. Using a good time source is very important. EDIT: Phil's point exactly. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [January 26, 2023, 8:05pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/26 "2023-01-26T20:05:25Z")
> [@zacharyw.larson](#): > > That tag is being historized, and I tried to explain my question was more implementation side less historian side. What exactly do you need help on for implementation? ---
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [January 26, 2023, 8:07pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/27 "2023-01-26T20:07:14Z")
Thanks guys I passed that along, but it would have to wait for a shutdown period to implement. For now for me to get correct shift uptimes, I think then it comes down to: **Option 1** Script sets the uptime tag to 0 at shift start. Running boolean tag on-change script to adds time to the uptime for running time from tags. Script toggles the boolean at -2 to shift end to insure I get the time. I collect data at -1 minutes to shift end. or **Option 2** Script sets the uptime tag to 0 at shift start. Running boolean tag on-change **script to query durationOn for time of the shift** Script toggles the boolean at -2 to shift end to insure I get the time. I collect data at -1 minutes to shift end. I think I will go with option 1 to avoid an additional database read. **Implementation** Or did I not understand the intended implementation of the tag history? This is the part I was not sure of I think. From a script that writes all the uptimes, or from the boolean tag on change script for example. Seems like there should be a historian query tag type, or that might be a small performance tax. ---
**Author:** ![plarochelle](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/plarochelle/32/29608_2.png) [@plarochelle](https://forum.inductiveautomation.com/u/plarochelle)\ **Post date:** [January 27, 2023, 8:42pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/28 "2023-01-27T20:42:01Z")
Use the SQL Bridge module. [Hour and Event Meters - Ignition User Manual 8.0 - Ignition Documentation](https://docs.inductiveautomation.com/display/DOC80/Hour+and+Event+Meters) ---
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [January 27, 2023, 9:41pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/29 "2023-01-27T21:41:24Z")
Thanks I think that works well with groups that are run every second. I am getting my reports at the end of the shifts. ---
**Author:** ![DNice](https://avatars.discourse-cdn.com/v4/letter/d/858c86/32.png) [@DNice](https://forum.inductiveautomation.com/u/DNice)\ **Post date:** [February 2, 2023, 2:58pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/30 "2023-02-02T14:58:40Z")
> [@zacharyw.larson](#): > > start. > Running boolean tag on-change script to adds time to the uptime for runni I think both these options are overkill. I am with @dkhayes117 on this with his post on Jan 25. If you have some kind of state tag being historized (1=ON,0=OFF) and only need the uptime report on a historical time frame (vs real time which your method may be better for) then I would use the script he presented. The only change needed to that script is to wrap the aggregationMode in [brackets]. ---
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [February 3, 2023, 1:44pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/31 "2023-02-03T13:44:48Z")
@DNice Are you describing this: **Option 2** Script sets the uptime tag to 0 at shift start. Running boolean tag on-change **script to query durationOn for time of the shift** Script toggles the boolean at -2 to shift end to insure I get the time. I collect data at -1 minutes to shift end. **Or what is the implementation you are describing?** **My concerns:** Triggering the script once at the end of the shift Capturing specifically the shift data only including over the midnight shift Excluding time outside of the shift Having a 0 at the shift start for my trending of the historized tag ---
**Author:** ![DNice](https://avatars.discourse-cdn.com/v4/letter/d/858c86/32.png) [@DNice](https://forum.inductiveautomation.com/u/DNice)\ **Post date:** [February 3, 2023, 2:23pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/32 "2023-02-03T14:23:09Z")
@zacharyw.larson, Really depends on what you want. If you want the uptime seconds between 2 timestamps (shift start/end), the historian query is how I would approach this. If you want a continuous uptime seconds tag then you could go with the options you mentioned or alternatively use a [event/hour meter](https://inductiveuniversity.com/videos/hour-and-event-meters/8.1) that keeps the uptime counts for you. You can set up a single ShiftEnd tag that can reset all the counter tags for ea machine. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [February 3, 2023, 2:30pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/33 "2023-02-03T14:30:14Z")
The beauty about using tag historian is you don't need to worry about resetting or rollovers. If you simply want to do a shift counter, do it in the PLC. ---
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [February 3, 2023, 3:10pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/34 "2023-02-03T15:10:32Z")
> [@zacharyw.larson](#): > > **Option 1** > Script sets the uptime tag to 0 at shift start. > Running boolean tag on-change script to adds time to the uptime for running time from tags. > Script toggles the boolean at -2 minutes to shift end to insure I get the time. > I collect data from the tag at -1 minutes to shift end in a transaction group that runs at that time. I am doing this Option 1 right now. **Hour meter** doesn't work for this, I am not running the transaction every second. I don't have accurate **clocks in the PLCs**. I can't fix that, it is not in my control. **Historian query** doesn't work so far, unless someone can explain an implementation that overcomes the concerns. **My concerns:** Triggering the script once at the end of the shift Capturing specifically the shift data only including over the midnight shift Excluding time outside of the shift Having a 0 at the shift start for my trending of the historized tag ---
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [February 3, 2023, 4:05pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/35 "2023-02-03T16:05:45Z")
I am just going with Option 1. I can't spend more time on it. **Option 1** Script sets the uptime tag to 0 at shift start. Running boolean tag on-change script to adds time to the uptime for running time from tags. Script toggles the boolean at -2 minutes to shift end to insure I get the time. I collect data from the tag at -1 minutes to shift end in a transaction group that runs at that time. ---
**Author:** ![zacharyw.larson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/zacharyw.larson/32/23749_2.png) [@zacharyw.larson](https://forum.inductiveautomation.com/u/zacharyw.larson)\ **Post date:** [February 7, 2023, 2:15pm UTC](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012/36 "2023-02-07T14:15:49Z")
@DNice thanks for the message. I should have clarified this pertinent detail of my requirements: Resetting the uptime tag to 0 at shift start creates sawtooth appearance for historical inspection. Makes visual inspection easier. [Previous page](https://forum.inductiveautomation.com/t/counting-uptime-techniques/69012.md?page=1)