PLC-LadderPLC timers explained: how TON, TOF and TP function blocks work, their IN, PT, Q and ET pins, and real ladder and FBD examples for each timer type.
PLC timers are how logic gets a sense of time: run the fan five seconds after the burner lights, keep the conveyor going thirty seconds after the last box, pulse the horn for exactly two seconds. IEC 61131-3 defines three standard timer function blocks — TON, TOF and TP — and every brand of PLC implements them, whether you program in ladder, FBD or Structured Text. This post explains all three, pin by pin, with the classic circuit for each, and covers the mistakes (frozen timers, reused instances) that account for most timer bugs in the field.
PLC Timers Explained: The Four Pins Every Timer Shares
All three timers are function blocks — they keep internal state between scans, so each one needs an instance name (FanDelay : TON). They share one interface:
| Pin | Direction | Type | Meaning |
|---|---|---|---|
IN |
input | BOOL | The condition being timed |
PT |
input | TIME | Preset time, e.g. T#5s, T#250ms |
Q |
output | BOOL | The timed result |
ET |
output | TIME | Elapsed time so far (great for HMI progress bars) |
The three blocks differ only in how Q responds to IN — and each answers a different plant question.
TON — On-Delay: "Has It Been True Long Enough?"
Q turns TRUE only after IN has stayed TRUE continuously for PT. If IN drops early, the timer resets to zero — TON has no memory of partial progress.
Classic use: delayed start. The burner ignites, and the combustion fan must prove itself before fuel opens; a motor starts, and the seal-air blower gets 5 s of head start. Also the standard debounce: a flaky level switch feeding a TON with PT := T#2s must hold its state two full seconds before the logic believes it.
In ladder, the block sits on the rung with the condition feeding IN and Q examined on the next rung; in FBD the same block sits in the network with wires. In ST:
FanDelay(IN := Burner, PT := T#5s);
FuelValve := FanDelay.Q AND Burner;
TOF — Off-Delay: "Keep It On a Little Longer"
Q turns TRUE the instant IN does — but when IN drops, Q stays TRUE for another PT before releasing.
Classic use: run-on. The bathroom-fan pattern at industrial scale: cooling fan runs 30 s after the drive stops, lube pump keeps oiling while the spindle coasts down, conveyor empties itself after the upstream machine halts.
RunOn(IN := DriveRunning, PT := T#30s);
CoolingFan := RunOn.Q;
A retriggering detail worth knowing: if IN comes back TRUE during the off-delay, Q simply stays TRUE and the delay starts fresh at the next falling edge.
TP — Pulse: "Exactly This Long, No Matter What"
On a rising edge of IN, Q fires TRUE for exactly PT — regardless of whether IN was a 10 ms blip or is still held TRUE. While the pulse runs, further edges are ignored.
Classic use: fixed-duration actions. Sound the horn 2 s before the machine starts, fire the glue gun 250 ms per part, flash a beacon. TP is the answer whenever "press and hold" must not mean "longer output."
HornPulse(IN := StartRequest, PT := T#2s);
Horn := HornPulse.Q;
The Three Side by Side
For the same input waveform — a button held 3 s with PT = T#5s, then held 8 s:
- TON: nothing on the 3 s press (never reached 5 s); Q rises at second 5 of the 8 s press and drops with the button.
- TOF: Q mirrors the button but hangs on 5 s after each release.
- TP: each press yields one clean 5 s pulse, whether the press was 3 s or 8 s.
Sketching that timing diagram from memory is the real test of understanding timers — and watching it live is better still: build all three in the PLC-Ladder simulator with one shared input, and toggle it while the three Q outputs animate. The FBD view makes the comparison especially clean, with one input wire fanning out to three blocks; if FBD is new to you, the Function Block Diagram Complete Tutorial covers the notation.
The Two Bugs That Cause Most Timer Tickets
The frozen timer. A timer only advances when it is called, and it's called when its rung or network or ST line executes. Put the call inside an IF (or on a rung whose preceding logic skips it) and the timer stops mid-count whenever the branch isn't taken — then resumes later with stale elapsed time. Rule: call every timer instance once per scan, unconditionally, and do the conditioning at its IN pin.
The shared instance. Two rungs using Delay1 are not two timers — they are one timer being called twice per scan with (probably) different IN values, and the second call wins. Symptoms are timers that never finish or finish instantly. One timed job, one instance, one call.
A third, subtler one: timers measure in scan-resolution steps. A T#10ms preset on a PLC scanning every 12 ms will be late; don't ask timers for precision finer than the scan (that territory belongs to high-speed hardware).
Where Timers Lead Next
Timers and counters are siblings — both are stateful blocks with the same instance discipline — and counters add the edge-detection trap that catches every beginner exactly once; that's the subject of PLC Counters Explained: CTU, CTD and Why Edge Detection Matters. And to see TON, TOF and TP doing real work inside complete circuits — flashers, star-delta starts, alarm delays — they feature heavily in FBD Programming Examples: 8 Real Circuits Explained Block by Block. Build the three-timer comparison first, though; ten minutes with a simulator makes the timing diagrams permanent. Visit PLC-Ladder Website