The on-delay timer, or TON, is the workhorse timer of PLC programming - the one you reach for when you want something to happen a set time after an input turns on. Its logic is simple to state: while the input stays true, the timer counts up, and when it reaches its preset the done bit turns on. Behind that simplicity are four parts worth knowing - the preset, the accumulator, the timing bit, and the done bit - and a handful of everyday oilfield uses, from ignoring a bouncing level switch to holding off before declaring a well has gone low on flow. It is the first timer most programmers learn and the one they use most.
On-Delay Timer (TON) in one line: An on-delay timer (TON) delays an action until its enabling input has been true for a preset length of time. While the input is true it accumulates elapsed time; when the accumulated value reaches the preset, its done bit turns on. If the input goes false before the preset is reached, the accumulated value resets to zero, so the delay restarts on the next attempt.
A TON is built from a few pieces that together define its behavior. The preset (PRE) is the target time you set - how long the input must stay true before the timer finishes. The accumulator (ACC) is the running count of elapsed time; it starts at zero and climbs while the input is true. The comparison between accumulator and preset is what drives the timer's outputs, so the whole instruction is really the story of the accumulator racing up toward the preset.
Two status bits report where the timer stands. The timer-timing bit (TT) is true while the timer is actively counting - that is, while the input is true and the accumulator has not yet reached the preset. It is the timer says it is in progress. The done bit (DN) turns on when the accumulator reaches the preset and stays on as long as the input remains true. Between them these bits let the rest of the program react to the three states a timer can be in: not started, timing, and done. An enable bit (EN) also tracks whether the timer is enabled at all, mirroring the rung input.
The reset behavior is the defining trait of a TON and the thing to keep straight. If the input goes false at any point before the accumulator reaches the preset, the accumulator immediately resets to zero and the done bit stays off - the partial time is discarded. When the input goes true again, the timer starts counting from zero, so the full preset delay must elapse again. This automatic reset-on-false is exactly what makes a TON a delay rather than an accumulator: it measures continuous true time, not total true time, which is precisely the opposite of a retentive timer.
The TON has a mirror-image sibling, the off-delay timer (TOF), and understanding the pair clarifies what each is for. A TON delays the turning on of its result: the done bit comes on after the input has been true for the preset. A TOF delays the turning off: its done bit turns on immediately when the input goes true and stays on for the preset time after the input goes false. One delays action after a start; the other extends a condition after a stop. Choosing between them is a matter of which edge you want to delay - the rising edge or the falling edge.
Both differ fundamentally from the retentive timer, and the difference is the reset behavior. A TON, like a TOF, resets its accumulator automatically when its input goes false, so it needs no separate reset instruction and always measures from a clean zero on each new attempt. A retentive timer refuses to do that, holding its accumulated value across interruptions and requiring an explicit reset. That single distinction - automatic reset versus manual reset - is what separates a delay from a total, and it is the first thing to check when deciding which timer a task needs.
For the common job of delaying an action after an input turns on, the TON is almost always the right tool, precisely because it starts fresh each time. You want a compressor-start delay or a low-flow confirmation to measure the current continuous condition, not a total that accumulated across earlier, unrelated events. Reaching for a retentive timer here would leave stale accumulated time that makes the delay fire early or immediately, which is the mirror of the mistake of using a TON where you needed to accumulate. Matching the timer to whether you want continuous or total time is the core decision.
The most common oilfield use of a TON is debouncing a noisy discrete input, such as a level or flow switch. A float switch on a tank or a paddle switch on a line can chatter - flicking on and off rapidly as liquid sloshes or flow fluctuates - and acting on every flicker would trigger spurious alarms and nuisance control actions. Feeding the switch through a TON requires the condition to hold true for the preset time before it is believed, so a brief chatter that clears before the preset is simply ignored. The TON turns a jittery signal into a stable, trustworthy one, and its reset-on-false behavior is exactly what makes this work: any interruption before the preset discards the count and demands a fresh, sustained signal.
TONs also protect and pace equipment. Delaying a compressor or pump start after the run command - waiting a few seconds for permissives to settle, or staggering starts so several motors do not inrush at once - is a textbook TON job. So is confirming a fault condition before acting on it: rather than shutting a well in the instant flow dips, a TON can require the low-flow condition to persist for a set time before it is declared, filtering out momentary dips from slugging or measurement noise that would otherwise cause unnecessary shutdowns. In each case the TON adds a deliberate buffer of continuous-condition time between a raw signal and a consequential action.
These same delays interact with the monitoring layer above the controller. A cloud SCADA platform such as Merobix reads the results of that logic - the confirmed low-flow condition, the debounced level, the delayed start - and historizes them, so what reaches an operator's dashboard and alarm list is the filtered, TON-qualified event rather than the raw chatter. That keeps remote alarming meaningful: a low-flow alarm that only fires after the condition has genuinely persisted is far more trustworthy to a lean field team than one that trips on every transient dip, and it means a truck is rolled for a real condition rather than a moment of noise. The humble TON, doing its filtering down in the PLC, is part of what makes remote monitoring credible.
A TON resets its accumulated value to zero the moment its input goes false, so it measures continuous true time and restarts each attempt - ideal for delays. An RTO retains its accumulated value across interruptions and requires an explicit reset, so it measures total true time across many cycles - ideal for accumulating runtime. The reset behavior is the key distinction: automatic for a TON, manual for an RTO.
The preset is the target time you set - how long the input must stay true before the timer finishes. The accumulator is the running count of elapsed time, climbing from zero while the input is true. The done bit turns on when the accumulator reaches the preset and stays on while the input remains true, while the timer-timing bit is true only while the timer is actively counting.
You feed a noisy discrete input, like a chattering level or flow switch, through a TON so the condition must stay true for the preset time before it is believed. A brief chatter that clears before the preset is discarded because the timer resets on false, so only a sustained signal gets through. This turns a jittery switch into a stable input and prevents nuisance alarms and control actions from momentary flicker.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.