Retentive On-Delay Timer and Timer Reset

The Core Idea

A retentive timer accumulates elapsed time across separate periods of operation. Unlike a timer that starts fresh when its input clears, it holds the accumulated time until the program explicitly resets it.

What you will learn

• Add up a machine's running time across interruptions with a retentive on-delay timer.

• Explain why an ordinary on-delay timer (TON) cannot do this: it starts again from 0 every time.

• Clear the total with a timer reset, and only under the condition the specification states.

Why it matters

Some requirements concern total running time rather than one uninterrupted run. The timer's hold and reset behavior must match the quantity you want to measure.

The problem

A pump needs service after a set amount of running time, however that time is split into separate runs. Real service intervals are hundreds of running hours; this lesson shortens the interval to 5000 ms so you can watch it happen.

The specification:

1. Every run adds to the total. Stopping the pump must not lose the time already counted.

2. When the total reaches 5000 ms, SERVICE_DUE turns on and stays on, even after the pump stops.

3. Service Reset clears the total and the lamp, but only while the pump is stopped. A press during a run is ignored, so nobody can wipe the total by accident while the pump works.

An ordinary on-delay timer (TON, from the on-delay timer lesson) clears its accumulated time whenever its enable goes FALSE, so it measures one continuous run. A retentive on-delay timer keeps its accumulated time when its enable goes FALSE and carries on from there when the enable returns. It stops at its preset, turns on Done, and keeps both until a timer reset instruction clears them. IEC 61131-3 (the international standard for programmable controller languages) has no standard retentive on-delay timer, so each platform names its own; see the platform notes at the end.

"Retentive" here means the timer keeps its time while its enable is FALSE. What happens to stored values when the controller loses power is a separate question, covered in a later lesson on power loss and retentive memory.

Predict

The demo runs RUN_TIME beside an ordinary on-delay timer, THIS_RUN, on the same PUMP_RUNNING input. Both have a 5000 ms preset.

Click PUMP RUNNING to switch the pump on and off; it stays where you leave it. Run the sequence from the question and watch TOTAL RUN ms, THIS RUN ms, and SERVICE DUE.

Try it

Keep using the demo above. It appears once you lock in a prediction.

1. While the pump is off, compare the two displays. TOTAL RUN ms holds its value; THIS RUN ms is back at 0.

2. Once SERVICE DUE is lit, switch the pump off. The lamp stays on, and the total stays at 5000 ms.

3. Switch the pump on and press SERVICE RESET. Nothing changes.

4. Switch the pump off and press SERVICE RESET. The total returns to 0 and the lamp goes out. The next run starts a new total.

Look closer

Pause, then use Step one scan while the pump runs. The scan stepper panel shows each timer's ACC, PRE, and Done.

• Rung 1 enables the retentive on-delay timer RUN_TIME from a normally open PUMP_RUNNING contact. Each scan with the pump running adds one scan's time, 100 ms, to ACC.

• In the scan where the pump stops, the timer's enable goes FALSE and ACC simply stays where it is. When the pump starts again, ACC carries on from that value. THIS_RUN in the last rung drops to 0 instead.

• At 5000 ms, ACC stops at the preset and Done turns on. Rung 3 copies Done to SERVICE_DUE. Stopping the pump changes neither.

• Rung 2 is the timer reset: SERVICE_RESET in series with a normally closed PUMP_RUNNING contact. Only in a scan where that rung is TRUE does ACC return to 0 and Done turn off. The reset rung comes before rung 3, so the lamp goes out in the same scan.

Nothing else in the program can clear RUN_TIME. That is the point: the total changes only by counting up while the pump runs, or by a deliberate reset.

Change it

In this practice program, the timer reset works on any press of Service Reset. Use the editor's tag list: set PUMP_RUNNING TRUE and let the total build for a second or two. While the pump still runs, set SERVICE_RESET TRUE and then FALSE. The total is lost, which the specification forbids. Add the missing condition to the reset rung, then repeat: the press during a run should do nothing, and a press with PUMP_RUNNING FALSE should clear the total.

Show the guided change

Add a normally closed PUMP_RUNNING contact in series with the SERVICE_RESET contact on the timer reset rung. A normally closed contact passes power only while its tag is FALSE, so the reset can act only while the pump is stopped. The timer rung and the lamp rung do not change.

Check yourself

Build a filter change reminder for a supply fan. The challenge editor opens with the tags FAN_RUNNING, FILTER_RESET, FILTER_TIME, FILTER_WARN, and FILTER_DUE, and no rungs.

• FILTER_WARN turns on once the fan has run 3000 ms or more in total.

• FILTER_DUE turns on at 4000 ms in total.

• Both stay on after the fan stops.

• Filter Reset clears the total and both lamps, but only while the fan is stopped.

In the editor's tag list, set FAN_RUNNING TRUE or FALSE to run the fan, and set FILTER_RESET TRUE and then FALSE to press Filter Reset. The checks use interrupted runs, a total of exactly 3000 ms, and a reset press during a run. Run them as often as you need.

Hint 1

Which timer keeps its total when the fan stops? And which value of that timer can tell you "3000 ms so far" before it is done?

Hint 2

Enable a retentive on-delay timer from FAN_RUNNING with a 4000 ms preset. Reset it from FILTER_RESET only while the fan is stopped. Compare its accumulated time for the warning, and use its Done bit for the due lamp.

Hint 3

The warning is a greater-than-or-equal comparison (GE) of FILTER_TIME.ACC with 3000. A greater-than comparison would miss a total of exactly 3000 ms.

Show the worked solution

1. A normally open FAN_RUNNING contact enables the retentive on-delay timer FILTER_TIME, preset 4000 ms.

2. A normally open FILTER_RESET contact and a normally closed FAN_RUNNING contact in series drive a timer reset for FILTER_TIME.

3. A greater-than-or-equal comparison, FILTER_TIME.ACC against 3000, drives the output coil FILTER_WARN.

4. A normally open FILTER_TIME.Done contact drives the output coil FILTER_DUE.

The accumulated time is kept while the fan is stopped, so both the comparison and Done see the true total, and both lamps stay on after the fan stops. Because ACC stops at the 4000 ms preset, the warning stays on once the filter is due. Only the reset rung can bring ACC back to 0, and only while the fan is off. Putting the reset rung first works too.

What happened and why

An ordinary on-delay timer answers "has this been TRUE continuously for this long?" A retentive on-delay timer answers "has this been TRUE for this long in total?" Stopping does not lose the time already counted, and reaching the preset is remembered, so the result survives the very interruptions that would reset an ordinary on-delay timer.

Because nothing clears the total by itself, the program has to say when a new total begins. That is the timer reset, and it is a decision: here, a service acknowledgement that only counts while the machine is stopped. The same pattern tracks running hours for maintenance, the total time a heater has been on, or how long a part has spent out of position across a shift. In each case, check the reset condition as carefully as the counting.

Common mistakes

• An ordinary on-delay timer. Cause: using the on-delay timer (TON) because the counting looks the same. Symptom: short runs never add up; the total drops to 0 at every stop. Fix: use the retentive on-delay timer.

• A reset with no condition. Cause: only the reset button on the timer reset rung. Symptom: a press during a run wipes the total. Fix: add the stated condition, here a normally closed contact on the running signal.

• No timer reset at all. Symptom: once the reminder comes on, nothing clears it. Fix: add a timer reset rung for the timer.

• A greater-than warning. Cause: comparing ACC with greater-than (GT). Symptom: a total of exactly 3000 ms leaves the warning off. Fix: use greater-than-or-equal (GE) for "3000 ms or more".

• A warning driven by Done. Symptom: the warning comes on at the due point, not before it. Fix: compare the accumulated time with the warning level.

Platform notes

IEC 61131-3 defines no retentive on-delay timer. The editor's Timers/Counters palette lists it as Retentive TON (drawn as RET TON on the rung) and the timer reset as T/C Reset (drawn as RESET), and the greater-than-or-equal comparison is GE on the Compare tab. Platforms name them differently:

The retentive on-delay timer is the RTO (retentive timer on) instruction, and the timer reset is the RES instruction, which also resets counters. The greater-than-or-equal comparison is GEQ.

The equivalent is the TONR (retentive on-delay timer) time accumulator. Its R input resets the elapsed time, so the reset is part of the timer block rather than a separate instruction.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.