A retentive on-delay timer, or RTO, is the timer that remembers. When its rung goes false, it does not throw away the time it has counted - it holds the accumulated value and picks up from there the next time the rung goes true again. That memory is what makes it different from an ordinary timer, and it comes with one non-negotiable rule: because it never resets itself, you have to reset it deliberately. In the oilfield the RTO is the natural tool for accumulating equipment runtime - pump and compressor hours - across all the stops and starts of normal operation, which is exactly why forgetting its reset is such a common and costly mistake.
Retentive Timer (RTO) in one line: A retentive on-delay timer (RTO) accumulates elapsed time while its rung is true and, unlike a standard on-delay timer, keeps that accumulated value when the rung goes false rather than resetting to zero. It resumes counting from where it left off when the rung goes true again and requires an explicit reset instruction to clear, making it ideal for totaling equipment runtime.
An RTO works on the accumulate-and-hold principle. While its rung is true it counts up, adding elapsed time to its accumulated value, and its done bit sets once that accumulated value reaches the preset. When the rung goes false, the RTO stops counting but crucially holds whatever it had accumulated - the value does not drop to zero. The next time the rung goes true, it continues from that held value rather than starting over. Over many on-off cycles, the accumulated value therefore represents the total time the rung has been true across all those intervals, not just the most recent one.
That retention is the whole point, and it is also why the RTO cannot reset itself. A non-retentive timer clears automatically the moment its rung goes false, so it never needs a separate reset. The RTO deliberately refuses to do that, which means the only way to bring its accumulated value back to zero is an explicit reset instruction - the RES instruction in Allen-Bradley terminology - addressed to that timer. Without a reset in the program, the RTO's accumulated value simply grows and persists indefinitely, which is desirable when you are totaling runtime and a bug when you are not.
The done bit behavior follows the same logic and catches people out. Because the accumulated value is retained, the done bit stays set once the preset is reached and remains set even after the rung goes false, until the timer is reset. This is very different from a standard timer, whose done bit drops as soon as its rung goes false. An RTO's done bit therefore means the accumulated time has reached the preset at some point and has not been cleared since - a latched condition that persists until reset, not a live reflection of the current rung state.
The choice between an RTO and a standard on-delay timer (TON) comes down to a single question: do you want the timing to survive an interruption, or should it start fresh every time? A TON is for delays that should restart on each attempt - wait five seconds after an input turns on before acting, and if the input drops the countdown resets so the next attempt gets the full delay again. That reset-on-false behavior is exactly right for a delay and exactly wrong for a total.
The RTO is for accumulation, where the interruptions are part of what you are measuring. If you want to know how long a pump has run in total, you do not want the count to reset every time the pump cycles off; you want it to pause and resume so the accumulated value reflects total runtime across every start and stop. That is the RTO's reason to exist. The rule of thumb is that a TON answers how long has this been true continuously right now, while an RTO answers how long has this been true in total, allowing for gaps.
Getting the choice backward produces predictable failures. Use a TON where you needed an RTO and your runtime total silently resets to zero every time the equipment cycles, so it never reaches a meaningful value - a maintenance interval that never triggers because the timer keeps forgetting. Use an RTO where you needed a TON and your delay never restarts, so accumulated time from earlier attempts makes the timer fire early or immediately on a later attempt. Because both timers look similar on a rung, this is an easy mistake to make and an easy one to overlook until the behavior is clearly wrong.
The RTO's signature application in oil and gas is run-hour accumulation for maintenance scheduling. Pumps, compressors, and engines are serviced on runtime rather than calendar time - so many hours between oil changes, filter swaps, or overhauls - and the RTO is the natural way to total those hours in the controller. Wired so its rung is true whenever the equipment is actually running, an RTO accumulates real operating time across every start and stop, and its done bit fires when the accumulated hours reach the service interval, flagging that maintenance is due. Because it retains through every cycle, the total reflects genuine runtime rather than an ever-restarting count.
The classic mistake is the one the RTO's design invites: forgetting the reset. Because the timer never clears itself, an engineer who wires up the accumulation but omits the RES instruction ends up with a runtime total that only ever grows and never returns to zero after service is performed. The maintenance-due bit latches on and stays on, or the next interval is measured from the wrong baseline, and the whole scheme stops meaning anything. The fix is to reset the RTO when maintenance is completed - typically from an operator acknowledgment or a service-complete input - so each interval is measured cleanly from the last service. Any runtime RTO without a corresponding reset path is a bug waiting to surface.
This is where cloud SCADA turns local runtime into a fleet-level tool. A platform such as Merobix can read each site's accumulated run-hours from the RTU and historize them centrally, so instead of runtime living only in one controller where a reset has to happen locally, the hours across every pump and compressor in the field are visible on one dashboard. Maintenance can then be planned across the fleet - which units are approaching their interval, which are overdue - and the cloud record provides a backstop if a local timer is reset or lost, letting a lean operation schedule service by actual runtime across many remote sites rather than guessing site by site.
A TON is a standard on-delay timer whose accumulated value resets to zero the moment its rung goes false, making it right for delays that should restart each attempt. An RTO retains its accumulated value when the rung goes false and resumes from there, making it right for totaling time across many on-off cycles. In short, a TON answers how long something has been true continuously, while an RTO answers how long in total.
Because it never clears itself - retaining the accumulated value across rung transitions is its whole purpose, so the only way to bring it back to zero is an explicit reset such as an RES instruction. Its done bit also stays latched once the preset is reached until the timer is reset. Without a reset in the program, the accumulated value grows indefinitely, which is a common bug when the timer is used for anything that needs to start over.
You wire the RTO so its rung is true whenever the equipment is running, and it accumulates real operating hours across every start and stop because it retains through each cycle. Its done bit fires when the total reaches a service interval, flagging that maintenance is due. The essential step is to reset the timer when maintenance is completed, so each interval is measured cleanly from the last service - forgetting that reset is the classic runtime-timer mistake.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.