Rolling 24 hour runtime for a pump display

What the total actually measures

A rolling window answers one question: how long was the pump running during the preceding 24 hours? It is not a lifetime total or a total since midnight.

Because this design updates once per minute, its window ends at the most recent completed minute boundary. Runtime in the current, unfinished minute is excluded until that minute closes. Between updates, the displayed result is therefore the latest completed-window value, not a continuously changing measurement.

A duration of 24 hours contains 24 × 60 = 1,440 minutes. Each stored sample represents the runtime accumulated within one of those minutes. It does not simply record whether the pump was running at the sampling instant.

Use elapsed time to define the window. Local clock changes should not silently add or remove buckets. A calendar day affected by a clock adjustment is not necessarily the same duration as 24 elapsed hours.

Choose the running signal and storage unit

First decide what runtime means. A start command measures requested operation. A motor run indication measures reported operation. Process feedback may establish a different condition, such as confirmed circulation.

Choose the signal that matches the maintenance or reporting purpose. Document that choice beside the controller tags and display label. Do not label a command-based total as confirmed pump operation.

Accumulate elapsed running time throughout each minute. A single check at the minute boundary is not enough. If the pump runs for only part of a minute, that bucket must contain only that operating duration.

Use a documented controller timing method with sufficient resolution for the pump's switching pattern. Check its time base before converting an accumulator into seconds. The accumulator, history samples and running total must use compatible units.

Seconds are convenient for explaining the arithmetic, but avoid discarding fractional seconds separately from every bucket. Repeated truncation can create a persistent undercount. If needed, keep native timer ticks or another suitably fine integer unit throughout the calculation, then convert the total for display.

Select numeric types for the largest total and intermediate calculation, not just for one sample. With seconds as the storage unit, a full window can reach 86,400 seconds. A signed 32-bit integer can hold that value; a 16-bit integer cannot. Finer units require their own range check.

Keep 1,440 minute samples

A circular buffer is a straightforward way to manage the history. Allocate 1,440 elements and maintain an index pointing to the oldest sample, which is the next element to replace.

At each completed minute, the running-sum relationship is:

new_total = previous_total - oldest_sample + completed_sample

For example, suppose the previous total is 7,200 seconds. The oldest minute contains 20 seconds of operation, and the newly completed minute contains 50 seconds. The new total is 7,200 - 20 + 50 = 7,230 seconds.

The logical update is:

• Read the old value at the current buffer index.
• Calculate the replacement total by subtracting that value and adding the completed sample.
• Replace the old buffer element with the completed sample.
• Store the replacement total.
• Advance the index, returning to the first element after the last one.

A supported queue can implement the same principle. Follow the controller manufacturer's documentation for queue initialization, capacity and status handling. An empty queue must not be treated as if it contains valid historical samples.

The running sum keeps the arithmetic workload small. Summing all 1,440 elements is still useful as a diagnostic comparison, but it need not be the normal update method.

Advance the window once per minute

The minute event must advance the history exactly once. A condition that stays true across several controller scans can otherwise replace several samples for a single interval.

Use a supported periodic task or elapsed-time scheduler and record which interval has been processed. A one-scan pulse prevents repeated execution only if the underlying timing logic also detects each interval correctly.

Treat the minute update as one coordinated state change. Capture the completed runtime sample, update the history and total, advance the index, and establish the next accumulation interval in a controlled execution order. Avoid a read-then-reset arrangement that loses elapsed time between those operations.

For a normal one-minute bucket, runtime must lie between zero and 60 seconds, or the equivalent limits in the chosen storage unit. A value outside those bounds calls for investigation. Possible causes include an incorrect time-base conversion, a missed boundary, or duplicate processing.

Do not silently clamp an oversized sample to 60 seconds. That conceals a timing fault without reconstructing the missing history.

If execution pauses across several boundaries, one long accumulated value cannot generally reveal how runtime was distributed among the missed minutes. Either recover that distribution from valid timestamped records or mark the affected history as incomplete. The display should not present an uncertain total as fully known.

Define startup and restart behavior

Initialization is part of the measurement definition, not just housekeeping.

Starting with no history

Clear all buffer elements, the total, the index and the current-minute accumulator together. Start a fresh 60-second sampling interval. If alignment to clock minutes is required, handle the first partial interval explicitly rather than treating it as a complete minute.

Zero-filled history makes the numeric result a total of known runtime since initialization. It does not establish that the pump was stopped during the unavailable part of the preceding 24 hours.

Show a status such as History incomplete and track valid elapsed coverage. Only after 1,440 consecutive valid full-minute intervals does the buffer contain a complete 24-hour history.

Retaining history through a restart

Retain the buffer, total, index and timing metadata as a coherent set. Current-minute state also needs an explicit recovery rule. Retaining only the total, or only the buffer, is not enough.

Executing updates in one scan is not sufficient by itself to establish a consistent retained state after an unexpected interruption. Use the controller's documented retention behavior and a suitable recovery design. Check bounds and compare the stored total with a diagnostic sum before accepting recovered data.

Retained samples must also age during downtime. Simply resuming the old buffer makes the window pause while the controller is unavailable, which is not a rolling elapsed-time window.

If independent information establishes that the pump remained stopped, the design can insert zero-runtime intervals for that gap and expire older samples. If operation during the gap is unknown, preserve that uncertainty instead. A gap of 24 hours or more expires all pre-gap samples, but it does not prove that runtime during the gap was zero.

Format the result as HH:MM

When the total is expressed in seconds, calculate the display fields with integer arithmetic:

• hours = total_seconds DIV 3600
• minutes = (total_seconds MOD 3600) DIV 60

Here, DIV means integer division with the fractional part discarded. Format both fields with two digits and place a colon between them. A total of 7,380 seconds becomes 02:03.

Do not format the result as a time of day. A completely running 24-hour window must display 24:00, not wrap to 00:00. A fully stopped window displays 00:00.

Truncate seconds only when preparing the displayed value. Keep the underlying total at the selected measurement resolution. Rounding to the nearest minute could display more runtime than has actually accumulated.

Send the result, history status and last-update indication from the controller. The screen should present the measurement rather than create the history itself. For the separate question of what belongs on a viewing screen versus a machine interface, use the distinction in factory status display or operator HMI.

Keep this runtime indication separate from protective functions and machine interlocks. An informative total is not proof that a pump or process is safe.

Check the calculation before use

Commission the timing, history and display together. Useful checks include:

• Stopped input: With a known, fully stopped window, confirm a total of zero and a display of 00:00.
• Partial-minute operation: Apply a known running interval within a minute and confirm that only that duration enters the bucket.
• Single advancement: Confirm one buffer replacement for each completed interval, with no duplicate updates.
• Running-sum agreement: Compare the maintained total with an independent sum of all stored samples.
• Sample expiry: Confirm that an identifiable sample leaves after 1,440 subsequent minute advances.
• Range limits: Confirm every full-minute sample is within its allowed range and the total stays between zero and 86,400 seconds when stored in seconds.
• Restart recovery: Check the selected retention policy, downtime aging, incomplete-history indication and first interval after restart.
• Display formatting: Check leading zeros, discarded seconds and the full-scale value of 24:00.

Use controlled test inputs or a separate test instance without interfering with live machine control. Record expected totals before each check so that a plausible-looking display is not the only acceptance criterion.

The calculation is ready when the sample history, running total, elapsed coverage and displayed value all describe the same window. If any of those disagree, diagnose the timing or state handling before relying on the number.

Questions