PLC TON timer: elapsed time, done output, and a scan-by-scan check

A non-retentive TON (timer on-delay) makes its done output true only after its input has stayed true continuously for the full preset time. If the input is false when the block executes, elapsed time returns to zero and the done output becomes false. Two short true intervals do not add up to one completed delay.

Scope and terms before the calculation

IEC 61131-3:2025 Edition 4 defines the current suite of programmable-controller languages, including Ladder Diagram and Function Block Diagram. This note uses the common IEC-style timer interface: Boolean input IN, preset time PT, Boolean done output Q, and elapsed time ET.

Vendor names are not interchangeable. Schneider's documented TON exposes IN, PT, Q, and ET: a rising input starts the delay, a falling input resets it, and Q is true after the preset has elapsed while IN remains true. Rockwell's current Logix-style TON documentation describes the same non-retentive purpose with a timer structure containing .PRE, .ACC, .EN, .TT, and .DN. In that vocabulary, .DN is the done bit and .ACC is accumulated milliseconds. Always use the target controller's manual rather than translating member names by resemblance.

Three timing quantities also need separation:

• Preset time (PT) is the requested on-delay: 3,000 ms here.
• Elapsed time (ET or vendor equivalent) is the timer's current accumulated continuous true time, capped at the preset in this worked model.
• Task cycle time is how often the PLC task is intended to execute. It is not the preset and it is not perfectly constant. CODESYS defines periodic jitter as actual task cycle time minus the configured ideal cycle time.

Worked scenario, inputs, and assumptions

A fictional ventilation controller should set AIRFLOW_PROVEN only after both FAN_CMD and AIRFLOW_OK have remained true for three seconds. The status may be useful for ordinary sequencing or diagnostics. It is not treated as a safety function, proof of actual volumetric flow, or permission to expose people or equipment to a hazard.

The reproducible timing model uses these inputs:

For an uninterrupted true interval that begins at t_rise, the teaching calculation is:

ET(t) = min(t - t_rise, 3000 ms)
Q(t)  = IN AND (ET >= 3000 ms)

When IN is false at an execution, this non-retentive model sets ET = 0 ms and Q = false.

Reproducible Schematex source

ladder "Airflow prove-on delay"
rung 1 "Fan command and airflow stay true for 3 seconds":
  XIC(FAN_CMD, "BIT 1.0", name="Fan command")
  XIC(AIRFLOW_OK, "IN 1.0", name="Airflow switch healthy")
  TON(AIRFLOW_TMR, PT=3000, name="3 s proof timer")
rung 2 "Ready only after proof timer completes":
  XIC(AIRFLOW_TMR, "TMR 1.0", name="Timer done Q")
  OTE(AIRFLOW_PROVEN, "BIT 1.1", name="Airflow proven")

Schematex 1.0.13 strictly parsed and rendered this source with no diagnostics on August 30, 2026. Its current ladder syntax reference documents TON(timer_tag, PT=milliseconds) and the use of the timer tag as a downstream done contact. Rendering proves that the source and topology are accepted; it does not execute the timer, sample inputs, or validate controller-specific behavior.

Scan-by-scan result for one uninterrupted interval

Assume the combined first-rung condition becomes true exactly at the execution labeled scan 0. The first observation establishes the rising boundary, so ET starts at zero. Each following ideal scan contributes 100 ms.

The key boundary is scan 30: 3.0 s × 1,000 ms/s = 3,000 ms, so ET >= PT and Q becomes true. The next false execution clears both values. The second rung therefore drives AIRFLOW_PROVEN only while the timer's completed condition remains true.

Interrupted time does not accumulate

Now let the same input stay true for 1.2 s, go false for one execution, then become true again at 1.3 s.

The discarded 1.2 s is not added to the later 3.0 s. That is the defining review test for this non-retentive on-delay example. If an application must preserve elapsed state through a false input, mode change, controller stop, or power event, that is a different requirement and needs an explicitly selected, vendor-documented design.

Checks and invariants

Use these checks before accepting a timer rung or its diagram:

1. Done implication: whenever Q = 1, IN must still be true and the elapsed value must have reached the preset.
2. Reset implication: after an execution with IN = 0, both Q and elapsed time are zero in this model.
3. No hidden addition: elapsed time after a new rising edge depends only on the current uninterrupted interval.
4. Preset cap: the displayed elapsed value never exceeds 3,000 ms in the worked IEC-style model.
5. Single state owner: the timer instance is not reused by another rung or routine. Rockwell warns that overwriting timer-structure members can cause unexpected operation.
6. Continuous execution: the timer is called on every intended task cycle. A timer placed behind conditional execution, jumps, inactive states, or an unscheduled routine needs controller-specific analysis.
7. Unit check: Schematex's PT=3000 means 3,000 milliseconds. Do not copy that literal into a platform that expects a TIME value such as T#3s, a configured time base, or different parameter syntax.

Resolution, jitter, and the real completion time

The table is exact only under its stated 100 ms, zero-jitter, boundary-aligned assumptions. A physical input may change just after the input image is sampled, and a cyclic task observes conditions only when it runs. The first observable done state is therefore on the execution where the implementation determines that elapsed time has reached the preset—not at an infinitely precise external instant.

Do not “correct” that uncertainty by adding one arbitrary scan to PT. Instead, define the response requirement, identify input-update and task scheduling behavior, measure actual minimum and maximum cycle time and jitter, and test the target controller. Rockwell documents elapsed-time updating from the difference between the current and last timer scan; CODESYS exposes runtime cycle and jitter measurements. Those facts support measurement, not a cross-vendor promise that every timer has identical internal resolution.

Failure modes, limitations, and review boundary

Common failures are calling a 3,000 ms preset an exact three-second physical response guarantee, letting the timer execute only on some scans, sharing one timer tag between unrelated logic, assuming a done bit stays latched after the input falls, and translating .DN, Q, .ACC, and ET without checking the controller family. Another failure is treating a rendered ladder as proof that the control application compiles or behaves correctly. Schematex is a deterministic drafting and review tool, not a PLC runtime.

Paste the source into the Schematex playground, change PT=3000 to PT=500, and confirm that the figure changes only its documented preset—it will not animate. Then reproduce both tables in the target PLC's simulator or test environment, force one false execution at 1.2 s, and record actual task cycle, jitter, elapsed value, and done state. Accept the logic only when the observed reset and completion boundaries match the controller manual and the project's reviewed requirement.