Hour Meter Reset in 8.0.1: Trigger Isolation, Not Retention

Moving the hour meter to a Run-Always Expression Item separates its execution from the transaction-group trigger and provides the practical workaround for the reset failure observed after upgrading from 7.9.10 to 8.0.1. The Retentive setting is not the controlling issue when the same tag drives both the hour meter and the group trigger.

Reset decision path

1. Trigger the transaction group and read the hour-meter value at the start of the new transaction. If it begins at zero, the reset lifecycle is working; investigate any downstream display, logging, or query that shows an older value. If it carries the previous transaction's accumulated value, continue to the configuration check.
2. Open the hour-meter item configuration and confirm that Retentive is not selected. Do not move on until the saved configuration also shows it cleared. If it is selected, clear it, save the group, and repeat the trigger test. If it was already cleared, retention is not the resolving branch.
3. Compare the hour-meter driving tag with the transaction-group trigger. If they are different signals, inspect the group execution and reset sequence before changing item placement. If they are the same tag, treat trigger coupling as the primary diagnostic branch.
4. Move the hour meter to a Run-Always Expression Item. Confirm that the expression produces the intended run state independently of the transaction group's triggered execution.
5. Run two complete trigger cycles. Do not accept the workaround after only one cycle: the first establishes accumulated state, and the second proves whether the next transaction starts from zero.

Version and configuration baseline

The intended hour-meter behavior remains a reset between non-retentive transaction executions. The installation-specific regression is bounded to an upgrade from 7.9.10 to 8.0.1; that observation does not establish that every 8.0 release or every transaction-group configuration is affected. Record the exact installed version shown by the gateway before comparing results.

Trigger-coupling mechanism

A triggered transaction group has an execution boundary: it evaluates the trigger, processes its items, and writes or updates the transaction as configured. An hour meter also carries timing state while its driving condition is active. When one changing tag supplies both roles, its transition defines the group boundary and changes the timer input during the same execution event.

Retention and trigger coupling control different behaviors. Clearing Retentive requests non-retained timer state across executions. It does not remove ambiguity created when the timer's input transition is also the event that starts the group. A version-dependent change in evaluation order, item initialization, or state transfer can therefore expose the previous accumulated value even though retention is disabled.

The decisive test is signal separation, not repeated toggling of Retentive. If an independently executed hour meter resets correctly while the group-bound item does not, the database destination and the physical tag are not the first suspects. The failure lies at the interaction between item lifecycle and triggered group execution.

Run-always workaround procedure

1. Save a gateway backup containing the failing configuration. Label it with the installed software version and preserve the original group long enough to reproduce the problem.
2. Record the current hour-meter source, expression, units, and destination mapping. These fields must remain functionally equivalent after the move.
3. Create or relocate the hour meter as a Run-Always Expression Item. Configure its expression to follow the intended running condition rather than depending on the transaction group's one-time trigger evaluation.
4. Remove or disable the original group-bound hour-meter calculation so that two items do not calculate or write competing values. Confirm that only the intended item supplies the logged hour-meter result.
5. Save the configuration and observe the run-always item before triggering the group. It must update according to its driving condition while the group is otherwise idle.
6. Trigger the group, allow a measurable value to accumulate, end the cycle, and trigger it again. Confirm the new transaction begins at zero before approving the change.

This workaround changes the execution context, so review the destination mapping carefully. Relocating the calculation without preserving how its result reaches the transaction can fix the timer lifecycle while leaving the logged field stale or unmapped.

Verification criteria

Capture timestamps and meter values immediately before the first trigger, during accumulation, after the cycle ends, and immediately after the second trigger. This sequence distinguishes a failed reset from a display that has not refreshed or a destination that still contains the prior record.

Recurring diagnostic pitfalls

• Testing only one trigger: A reset-between-transactions defect requires two transactions. One cycle cannot prove that prior state was discarded.
• Treating retention as the only state control: An unchecked Retentive option does not decouple the hour-meter input from the group trigger.
• Changing several fields together: Move the hour meter first while preserving its source and mapping. Multiple simultaneous changes destroy the comparison needed to identify the resolving branch.
• Reading only the operator display: Compare the live expression item, group value, and stored transaction. A stale display and a failed timer reset produce similar symptoms but require different corrections.
• Removing the workaround after an upgrade without testing: Restore the original topology only in a controlled copy, then execute the same two-cycle acceptance test against the new software revision.

FAQ