Education · Timers & Delays

Timers & Delays Logic

Read a few real control sequences and a pattern emerges: almost nothing important happens the instant its condition goes true. Command the fan, then wait for proof before you believe it started. Keep the fan running for a while after the heat shuts off. Don't restart the compressor you stopped ninety seconds ago. Every one of those sentences is a timer — and the whole family on a wiresheet comes down to two blocks. This page is one question, start to finish: what do TON and TOF actually do — and why does almost every real sheet gate its decisions through time?

This page assumes you can read a sheet at the block level — pins, wires, and the scan. That's Function-Block Basics, the opening lesson of this chapter. Two neighbors get leaned on but not re-taught: this chapter's boolean-logic lesson owns what an SR latch is and why safeties latch, and its comparator lesson owns how a threshold decision gets made in the first place. Here, those blocks just do their day jobs — the timers are the story.

TON and TOF: two mirror sentences

A timer block does nothing clever with its input — no math, no comparison. It reshapes the input in time. The on-delay timer, TON, is the sentence "the input must stay true this long before I believe it." Its output stays FALSE until the input has been TRUE, continuously, for the full preset — then the output goes TRUE and follows the input for as long as it holds. The off-delay timer, TOF, is the mirror: "I keep saying true this long after it drops." Its output goes TRUE the instant the input does — no delay on the way up — and when the input drops, the output hangs on for the preset before letting go.

Both blocks carry the same two numbers. The preset (PT) is the parameter you type in — the length of the delay, in seconds. The elapsed time (ET) is the block's live progress toward it, counting up from zero. On a running sheet, ET is the readout that tells you what the timer is doing right now: a TON with ET climbing is an input being tested; a TOF with ET climbing is an output living on borrowed time.

BlockQ goes TRUEQ goes FALSEET measuresET clears when
TONafter IN holds TRUE for PTthe instant IN dropshow long IN has been TRUEIN drops
TOFthe instant IN risesafter IN stays FALSE for PThow long since IN droppedIN returns

The resets in that last column are where field intuition most often goes wrong, so make them explicit. A TON keeps no credit across attempts: if the input drops one second short of the preset, ET zeroes on the spot, and the next attempt starts the count from scratch. There's no partial credit, no memory of how close it came. (Timers that do accumulate across interruptions exist — some palettes call them retentive or accumulating timers — but that's a different block; don't assume you have one.) A TOF's reset runs the other way: if the input comes back before the preset runs out, the countdown is cancelled — not paused — and ET zeroes. The output never blinked, and the next drop starts a fresh, full-length delay.

Here are both blocks as timing traces — the one diagram every controls reference draws, because it answers at a glance what a paragraph struggles to. Top to bottom in each panel: the input, the elapsed time, the output.

TON and TOF timing diagrams Two stacked timing panels, each with three aligned traces: input IN, elapsed time ET, and output Q. In the TON panel, a first input pulse is shorter than the preset: ET ramps partway up and clears to zero the instant the input drops, and Q never fires. A second, longer input pulse holds: ET ramps up, reaches the preset line, and parks there; Q rises exactly when ET reaches the preset and drops the instant the input drops, with ET clearing at the same moment. In the TOF panel, Q rises the instant the input rises. When the input drops, Q holds while ET ramps toward the preset; at the preset Q finally drops and ET parks at the preset value. A second input pulse then drops out only briefly: ET ramps partway, the input returns before reaching the preset, ET clears, and Q rides straight through without ever dropping. TON — on-delay preset PT, elapsed ET IN ET Q PT PT dropped early — ET clears, Q never fires Q waits out the full preset — then follows IN down at once TOF — off-delay IN ET Q PT PT Q rises with IN — no delay up Q lets go at PT short dropout — Q rides through time → TON trims away any TRUE shorter than the preset; TOF fills in any FALSE shorter than it

ET climbs toward the preset and parks there — a TON holds it at PT while the input stays true, a TOF after the delay expires — until the opposite edge clears it. That's exactly how the simulator's blocks report it live.

Squint at the two output traces and a single idea covers both blocks: a timer is a minimum-duration filter. TON deletes every TRUE shorter than the preset — as far as anything downstream knows, a six-second blip into a ten-second TON never happened. TOF deletes every FALSE shorter than the preset — a brief dropout is invisible on the far side. Hold onto that framing, because every use in the rest of this page — proof windows, debounce, minimum times — is that one filter pointed at a different decision.

The proof window: fail-to-start, done right

Why does a sheet need time at all? Because the controller and the machinery live at different speeds. The sheet re-evaluates several times a second — every scan, fresh answers. A fan takes ten or fifteen seconds to spool up and make enough airflow to close its proof switch. So for the first several seconds of every perfectly healthy start, "commanded but not proved" is the honest state of the world. Logic that alarms on that condition directly will cry wolf on every start it ever supervises. The fix isn't a better comparison — it's a window of patience, and that window is a TON.

Here's the pattern in full, and it's worth learning wire by wire because it guards nearly every fan, pump, and compressor in a building: the fail-to-start alarm. The sentence first: "if the command is on and proof hasn't shown up within 15 seconds, something is wrong — and stay alarmed until someone looks." The Function-Block Editor ships this exact sheet as its proof-of-flow alarm example. Two binary inputs on the left: the fan command, and the proof — a status contact that closes when air actually moves. A NOT flips the proof into "proof is missing," and an AND combines: commanded, AND no proof — the failure condition. That condition feeds a TON with a 15-second preset — the proof window. The timer's output sets an SR latch, the latch drives the alarm output, and a reset input waits on the latch's R for a human. Here's the sheet eight seconds after the proof dropped:

The proof-of-flow alarm as a wiresheet A function-block sheet with eight blocks. Two binary inputs on the left: a fan command reading ON and a proof-of-flow status reading OFF. The status feeds a NOT block, so its output — proof missing — is TRUE. The command and the NOT output feed an AND block, whose output, commanded with no proof, is TRUE and feeds a TON on-delay timer with a 15 second preset; the timer's elapsed time reads 8 seconds and climbing, so its output is still FALSE. The timer output feeds the set input of an SR latch; a reset binary input, currently OFF, feeds the latch's reset input. The latch output, still FALSE, drives a binary output labeled ALARM, currently off. Three numbered phase markers annotate the sheet: phase one, healthy — with proof made the AND has a FALSE leg and the timer sits at zero; phase two, the drawn moment — proof lost eight seconds ago, elapsed time climbing toward the preset; phase three — if the elapsed time reaches 15 seconds the timer fires the latch and the alarm holds until reset, even if proof returns. Every wire on this sheet is digital: TRUE wires are green, FALSE wires grey. BINARY IN · PROOF STATUS OFF NOT no proof → TRUE BINARY IN · FAN CMD ON AND cmd + no proof TON PT 15 s · ET 8 s ↑ S R SR LATCH Q FALSE BINARY OUT ALARM OFF BINARY IN RESET OFF 1 2 3 1 — healthy — proof made: the AND has a FALSE leg and the timer sits at zero 2 — drawn here — proof lost 8 s ago: ET climbing toward the 15 s preset, alarm still off 3 — if ET reaches 15 s — Q fires S: ALARM latches ON and holds until RESET, even if proof returns

Every wire on this sheet is digital: green carries TRUE, grey carries FALSE — the same coloring the editor uses live.

Now watch what the timer buys you on a healthy start. Command goes on; the fan hasn't moved yet, so proof is missing and the AND goes TRUE — the failure condition is honestly true, for a moment. ET starts climbing. Eight, nine, ten seconds in, the fan makes airflow, proof closes, the NOT drops the AND's leg, and ET clears back to zero. Q never fired; nobody got paged. The TON deleted a TRUE that was shorter than the preset — the minimum-duration filter, doing exactly what section one said. The timer's whole job is to forgive every honest start and catch only the failure that outlasts the window.

And why the latch? Because the timer's output only lasts as long as the failure condition stands. Suppose the belt snapped: proof never comes, ET walks all the way to 15, the alarm should stand. But if an operator later switches the fan command off — a perfectly natural response — the AND drops, the TON releases, and without a latch the alarm would erase itself, evidence and all. The SR latch gives the trip a memory: the timer detects, the latch remembers, and only a deliberate reset — a person, acknowledging — lets go. (What a latch is, why set-dominance matters, and the latch + manual-reset idiom are this chapter's boolean-logic lesson; here it just does its day job.)

Don't take the diagram's word for it — the sheet is running in the Function-Block Editor. Load the proof-of-flow alarm example; it loads healthy, command and proof both made. Click the STATUS block and toggle it off — the belt just snapped. Watch the TON's ET readout climb, and try to beat it: toggle STATUS back on before 15 seconds and the count just vanishes — that's a recovery inside the window, no alarm. Break it again and let it run. At 15, the alarm latches — and now toggle STATUS back on and watch nothing change. The latch is holding. Flip RESET on and off again — that's the acknowledge — and the sheet is healthy again.

How long should the window be? It's a real decision with a failure mode on each side. Too short, and the alarm nuisance-trips on every honest start — the fan was coming; the logic didn't wait. Cry wolf often enough and the alarm gets ignored or, worse, disabled. Too long, and the window becomes a blind spot: a start that genuinely failed runs unreported for the whole preset, and anything the sequence interlocks against "proven" — electric heat that must never run without airflow — inherits that blind spot with it. The rule of thumb: as long as the slowest honest start you'll ever see, plus a little margin, and no longer. What the proof contact actually measures — and which failures each kind of proof source can even see — is a story of its own, and it belongs to this chapter's status-and-proof lesson.

The same filter works at a smaller scale, where it goes by the name debounce. Picture a DP switch set close to the fan's actual operating pressure: at marginal airflow it flutters, and the raw status point flips on and off several times a minute — spamming alarms and waking the whole change-of-value pipeline. A two- or three-second TON between the raw point and the logic means the status must hold made before anything believes it; the flutter never survives the filter. The mirror trick works too: a short TOF rides through brief dropouts instead. Just know what the timer is doing for you — it's treating the symptom. If the switch is fluttering because its setpoint has no margin against the operating point, the honest fix is the setpoint, not a longer filter.

Minimum run, minimum off: protecting equipment from its own decisions

The third job timers do isn't about believing inputs at all — it's about pacing outputs. A cooling call starts the compressor; ninety seconds later the space is satisfied and the call drops; two minutes after that, it's back. Every individual decision was correct. The pattern is destructive, because for a compressor the expensive part isn't running — it's starting. Locked-rotor inrush heats the windings faster than they can shed it; a short run pumps oil out into the circuit and never runs long enough to carry it home; and a stop leaves the system with a pressure difference across it that the next start has to fight if it isn't given time to equalize. Manufacturers publish a starts-per-hour budget for exactly this reason — and a sequence that ignores it is spending someone else's money.

The guard is a pair of timing rules, and both are the section-one filter pointed at the equipment's own state. Minimum run: once started, stay started for at least the minimum — a stop request younger than that isn't honored yet. Minimum off: once stopped, stay stopped — a start request has to wait out the off-time. Each rule is "this state must stand at least this long," which is an on-delay measuring the current state's age and gating the exit. Production palettes usually bake both into the equipment-enable block as min-on / min-off parameters; when you meet the logic built out in the open, it reads as a TON per state. Either way, the numbers come from the equipment's documentation, not from taste.

Here's where the timers meet the decision they're pacing. The on/off decision itself comes from a deadband — two thresholds with memory between them, this chapter's comparator lesson — and the two mechanisms divide the work cleanly: the band decides what the sequence wants; the timers decide when it's allowed. When the two are sized together, the timers almost never intervene — the band alone asks for cycles slower than the minimums. When the band is too narrow, you can watch the fight on a live sheet: the band says stop, the min-run timer says not yet, and the space sails past the threshold while the equipment holds on — occupants feel a thermostat being ignored. The timing did its job; the decision was wrong. Fix the band. An anti-short-cycle timer is the last line of defense, not a license to draw thresholds carelessly.

Zoom out from one compressor to a whole plant and the same two rules are running at system scale. The equipment-staging lesson's sequencer carries a stage delay — demand must hold across the threshold for a sustained period before a stage changes, an on-delay by another name — and a minimum stage time that blocks the next change after one lands: min-run and min-off at the stage level. Its interactive widget lets you feel both — drag the demand slider up and down quickly and the sequence refuses to chase you. How long those delays should be, and where the staging thresholds themselves belong, is that lesson's ground. One boundary worth naming so it doesn't blur: everything on this page is interval time — "how long since." Time-of-day control — occupancy schedules, optimal start — is calendar time, a different mechanism entirely, and there's no clock block on this simulator's palette.

Race the window yourself

The proof-of-flow sheet is the whole lesson in seven blocks, and it's already built. Load the proof-of-flow alarm example in the Function-Block Editor and break it: toggle STATUS off and watch ET climb on the TON. Beat the window once — proof back on at 12 seconds, count erased, no alarm. Then let it expire, watch the latch grab, and see for yourself that restoring the proof changes nothing until RESET. Finally, click the TON and shrink its preset to 3 seconds in the inspector, then break the proof again — feel how fast a too-short window turns an honest transient into a page at 2 a.m. That's the entire art of this block family: same timer, same sheet — the preset is the judgment call.

Open the Function-Block Editor →
← Back to Education