I have an hour meter set to be retentive with no reset condition. I am trying to set a hour meter for the life time of the device, but if i disable the transaction group and then enable the group the hour meter resets. Is there someway i can stop this behavior?
This is expected behavior. The best way to retain the hour meter values is to store them into the database so they aren’t lost on a group or gateway restart.
OK so I was just going to ask this same question.
How is it useful then to have it in the database if it is resetting to 0?
For exmple
I’m looking at trying to log up time for a plant. If the value is never reset then it is easy to query the table.
select max(uptime) as Uptime from table where timestamp between startdate and enddate
If the runtime resets to 0 everytime the transaction group etc… is reset then the query become much more difficult.
Our customers want to be able to query total uptime across a date and time range. If there is not a consistent retentive value then how can I figure out the runtime across a date and time range? Does ignition have any examples? Or is there a better way to accomplish this?
The transaction group isn’t meant to be restarted often. I know it sometimes does, especially while developing. There are two main ways to deal with this issue if you are using the database to store the uptime.
-
You could change your records to show the amount of uptime since the last execution. Then you can sum the uptime in the table over whatever time range to want.
-
You can use the expression items in the transaction group to determine when a restart has occured (current value < last value) and create a new record with the previous value as your totalizer entry. This can cause your database entries to not be regular.
I think the first is probably the best option. Regardless of how you do it, there’s always some case where your totalizer will reset and you have to plan accordingly.
If you absolutely must have accurate totalizing, the reliable solution is to run an odometer in the control system, and record that value at every important time boundary. Then use window aggregate functions to convert odometer values to interval totals when retrieving from the DB. The latter’s arithmetic must be coded to properly apply the rollover quantity in the intervals in which it occurs. Window aggregate functions can also yield totals if you simply record timestamps on every up/down state change, but aligning to hour/shift/day/week boundaries can get a bit tricky. Producing the timestamps in the PLC and using handshakes to ensure they are recorded offers the most precision.
1 Like
What did you end up doing?
Did you use a PLC hour meter, setup hour meters with script events, or something else?
I think till I learn a better way, I will use an event script.
When my machine switches state, I will calculate the time from the last switch, store the new time, and add the difference to a counter.