Timers Explained — TON, TOF, RTO in PLC Ladder Logic

 Timers Explained — TON, TOF, RTO in PLC Ladder Logic

Sooner or later, every rung you write needs to wait for something. A pump that shouldn't stop the instant its command drops, a damper that needs a few seconds to actually reach position before the fan is allowed to start, an alarm that shouldn't scream the moment a reading blips for half a second. Every one of those situations comes down to the same three instructions: TON, TOF, and RTO. Learn these three cold, and you've covered probably ninety percent of the timing logic you'll ever write on a real plant.

Why Timers Exist in the First Place

A plain contact and coil only know two states: on or off, right now, with no memory of how long anything has been true. Most real equipment doesn't behave that cleanly. A conveyor needs a few seconds of run-up before a downstream sensor is believed. A trip condition might need to persist for a second or two before it's treated as real, so a single noisy pulse from a sensor doesn't shut down a kiln. A pump might need to keep running for a short cooldown period after its command drops, so it doesn't deadhead against a closed valve.

Timers give ladder logic a sense of elapsed time. Instead of asking "is this true right now," a timer lets you ask "has this been true for long enough," or "has it been false for long enough." That distinction is the whole reason these three instructions exist, and it's also exactly where they differ from each other.

TON — Timer On-Delay

TON is the one you'll use constantly, so it's worth understanding thoroughly before touching the other two.

A TON timer starts counting the moment its input goes true, and it counts upward, continuously, for as long as that input stays true. Once the accumulated time reaches the preset value you've configured, the timer's done bit turns on — and that done bit is what you actually use elsewhere in your logic to trigger something.

Here's the part that trips people up the first time: the moment the input goes false again, before the preset is reached, the timer doesn't pause. It resets straight back to zero. There's no partial credit. If your preset is ten seconds and the input drops out at nine, you're not one second away from done — you're back at zero, waiting for another full ten seconds the next time the input goes true.

Think about a damper actuator on a kiln ID fan. You command it to open, but the physical damper takes a few seconds to actually travel to position — it's not instantaneous just because the command bit went high. A TON timer sitting on that "damper commanded open" signal, with a preset matched to the real travel time, gives you a "damper confirmed open" bit only after enough time has genuinely passed for the damper to have gotten there. The fan start permissive downstream watches that timer's done bit, not the raw command — so the fan can't start prematurely against a damper that's still mid-travel.

That's TON in one sentence: it delays turning something ON until an input has stayed true long enough.

TOF — Timer Off-Delay

TOF is built almost the opposite way, and once you understand TON, TOF is really just a mirror image of it.

A TOF timer's output turns on immediately, the instant its input goes true — no delay at all on the way in. The delay only shows up on the way out. When the input drops from true to false, the output doesn't drop immediately with it. Instead, the timer starts counting, and the output stays on for the full preset duration after the input has already gone false. Only once that preset time has elapsed does the output finally turn off.

This is the instruction you reach for whenever something needs to keep running a little longer after its trigger has already ended. A common example is a fan or pump cooldown. Say a motor's command drops out — maybe the process called for it to stop, or an operator hit Stop. But you don't necessarily want the physical equipment to cut off instantly; you might want a blower to keep running for another thirty seconds to clear residual heat, or a lube pump to keep circulating briefly after the main motor it protects has already stopped. Wire the motor's stop command into a TOF timer, and the output — which drives the actual cooldown equipment — stays energized for the preset duration after the main stop signal, then drops on its own once the timer finishes.

Notice the practical difference from TON: TON delays the turn-ON, TOF delays the turn-OFF. Same basic idea of "wait before doing something," but applied to opposite transitions.

RTO — Retentive Timer On

RTO looks a lot like TON at first glance — it also counts up while its input is true, and it also has a done bit that turns on once the accumulated value hits the preset. The difference is entirely in what happens when the input goes false.

Remember how TON resets to zero the instant its input drops? RTO doesn't. When an RTO's input goes false, the accumulated time simply freezes exactly where it is — it doesn't reset, and it doesn't keep counting either. It just holds. The next time the input goes true again, counting resumes from wherever it left off, not from zero. The only thing that ever resets an RTO's accumulator back to zero is a separate, dedicated reset instruction that you have to wire in deliberately.

This retentive behavior is exactly what makes RTO useful for accumulating total elapsed time across multiple separate occurrences, rather than measuring one continuous stretch. A classic example is tracking total running hours on a piece of equipment for maintenance scheduling — you want the accumulated runtime to keep building up across every start and stop the motor goes through over a shift, a week, a month, not reset back to zero every single time the motor happens to stop for a few minutes. An RTO wired to the motor's run signal keeps quietly building that total, pausing whenever the motor is off, and only clearing when you deliberately reset it — typically after maintenance has been performed and you want the clock to start over.

It's also worth being a little careful with RTOs, precisely because of that retentive behavior. If you forget to wire in a reset, or forget to actually trigger it when you meant to, that accumulator just keeps quietly holding old time from occurrences you may have intended to have been cleared already. That's usually not what a beginner wants for straightforward delay logic — which is exactly why TON, not RTO, is the default choice for most everyday timing.

Putting the Three Side by Side

It helps to line all three up against the same simple question: what does the timer do to its output, and what does it do to its accumulator, at each transition of its input?

TON — output turns on only after the input has been true for the full preset. Accumulator resets to zero the instant the input goes false.

TOF — output turns on immediately with the input. Output stays on for the preset duration after the input goes false, then turns off. Accumulator resets once that off-delay finishes.

RTO — output turns on after the input has been true for the full preset, same as TON. But the accumulator holds its value when the input goes false instead of resetting, and only a dedicated reset instruction clears it back to zero.

If you're ever unsure which one a piece of logic needs, ask yourself two questions. First: does the delay belong on the way something turns on, or on the way it turns off? That separates TON and RTO from TOF. Second: should the timer forget everything the instant the input drops, or should it remember and keep accumulating across separate occurrences? That's what separates plain TON from RTO.

Why This Matters on a Real Plant

Timers show up constantly once you start looking for them. A start permissive waiting on a damper to physically reach position is a TON. A lube pump cooldown that keeps running briefly after the main motor stops is a TOF. A running-hours counter feeding your preventive maintenance schedule is an RTO. Even something as simple as debouncing a noisy proximity switch — refusing to trust a signal until it's stayed steady for a fraction of a second — is a TON quietly doing its job in the background.

None of these three instructions are complicated on their own. What actually separates a technician who's comfortable with timers from one who isn't is recognizing, from the behavior the process needs, which of the three transitions you're actually trying to delay — and whether the timer needs to forget or remember what happened last time.

Recap

TON (Timer On-Delay) — delays turning an output ON. Resets to zero the moment the input goes false.

TOF (Timer Off-Delay) — output follows the input immediately on the way up, but delays turning OFF after the input drops.

RTO (Retentive Timer On) — behaves like TON on the way up, but holds its accumulated value when the input drops instead of resetting. Needs a dedicated reset instruction to clear.

Ask yourself which transition needs the delay — turning on or turning off — and whether the timer should forget or remember between occurrences. That question alone gets you to the right instruction almost every time.