IEC Timer Instructions: Instances, Call Order and Timing

Use this IEC timer instructions reference when a timer appears to have the right preset but the surrounding program still produces the wrong result. The central questions are which instance stores the timing state, when that instance is called and whether the consuming logic reads its output before or after the call.

TON, TOF and TP are useful names for on-delay, off-delay and pulse behaviour. They do not remove the need to check the selected library, operand types, startup conditions and calling rules. This page uses explicit software models to examine those details, with primary vendor references for comparison.

For the introductory timing tables, start with the PLC timers and counters tutorial. This reference goes deeper into integration: connecting a correctly behaving timer to a program that reads and resets it in a deliberate order.

Read the timer interface as a stateful contract

A function-block instance owns stored state. Its name is more than a label printed beside a rectangle. A start timestamp, elapsed value, output and any input history belong to that instance across the calls defined by the runtime.

In a common named-parameter form, IN is a Boolean input, PT is a time preset, Q is a Boolean output and ET is an elapsed-time value. Verify the actual declaration rather than assuming a bare number is a duration in seconds or that a vendor's Done field is interchangeable with every Q output.

The CODESYS TON reference shows an instance declaration, a call with IN and PT, and a subsequent read of the instance's Q output. That is a useful concrete pattern for reading a function-block interface. The chosen instance still needs a suitable lifetime in the containing program.

A temporary object recreated with every evaluation cannot be assumed to retain the state required by a delay. Equally, a retained object reused for a different purpose can carry old state into the new purpose. Document the lifecycle rather than leaving it implicit.

Choose the Boolean behaviour before choosing the display field

For an on-delay requirement, Q stays false until the required uninterrupted true interval has elapsed. Evaluating a false input resets an ordinary non-retentive on-delay under the model used here.

For an off-delay requirement, Q is true while the input is true and remains true during the defined delay after an observed falling transition. A timing indicator, if the implementation provides one, is not the same thing as that output.

For a pulse requirement, a qualifying event starts a defined active interval. State what happens to another event arriving while active, at expiry and after expiry. A requirement to extend a pulse on every new event is different from a requirement to ignore those events.

Do not infer a complete operating state from ET alone. Zero elapsed time might mean an inactive timer, a newly started interval or a reset interval, depending on the instruction. A completed elapsed value also does not tell you whether a separate permission currently allows an output command.

Keep the display field's meaning explicit: “delay complete”, “pulse active” and “accumulated duration reached” describe different facts. A single label called “timer on” often hides the distinction that a troubleshooting exercise needs to expose.

02

Read Q after the call when you need the current result

Consider a supplied-time on-delay model with a fixed preset of 1,000 milliseconds. The instance begins reset, with Q false. A false input clears its start time and Q. The first true evaluation stores the current timestamp, and later true evaluations compare elapsed time with the preset.

Within each routine call, save BeforeQ, evaluate the timer, then save AfterQ. The difference between those saved values shows exactly where the instance updated.

BeforeQ = Delay.Q
EvaluateDelay(CurrentTime, Input, Preset = 1000)
AfterQ = Delay.Q

At 1,010 ms, a reader placed before the timer call still sees the previous false output. A reader after the call sees true. At 1,020 ms, the reverse happens: the earlier reader still sees true, while the executed false input makes the later reader see false.

This is a call-order effect. It is not a rule that dotted outputs can only be read on the next scan. The value available to a particular reader depends on which updates have occurred before that reader executes.

The table was checked in an independent software model. Use it as an expected trace for your own implementation and record the observed values. It does not establish the behaviour of an untested native timer project or physical output module.

For broader context, the scan-cycle explanation distinguishes sequential program assignments from the timing of actual I/O updates.

Avoid sharing one timing history between independent conditions

Suppose ConditionA is continuously true and ConditionB continuously false. Two independent one-second delays should produce a completed A delay after one second and an incomplete B delay throughout.

Now imagine calling the same instance once with A and then again with B at the same supplied timestamp. In the model, the A call begins a timing interval, but the B call immediately resets that same interval. The next evaluation repeats the sequence from reset state.

The shared result is explainable; it does not require mysterious corruption. Two calls are applying contradictory inputs to one history. The intended two independent timing requirements were never represented by two independent states.

The Schneider Machine Expert TON documentation discusses instance declaration and uniqueness in its documented context. Use the target environment's supported instance arrangement rather than assuming that a particular database or storage mechanism applies to every vendor.

For review, list every call that refers to the instance. Include calls hidden inside helper routines or reused function blocks. Then identify which timing requirement owns the state and whether another call can reset or advance it unexpectedly.

03

Distinguish a skipped call from a call with IN false

If a routine does not call a timer, the timer has not processed that evaluation's input. If the routine calls it with IN false, the timer can execute its documented false-input behaviour. These operations are not interchangeable.

Use a second supplied-time model to make the distinction visible. Start a two-second on-delay at time zero with IN true. At 1,000 ms, skip the call completely. At 2,000 ms, call it again with IN true. In this particular timestamp-based model, the original start time remains zero, so the resumed call observes two seconds elapsed and sets Q true.

In the comparison run, execute IN false at 1,000 ms. That clears the interval. The true call at 2,000 ms now starts a new interval with zero elapsed time and Q false.

This deliberately defined model shows why “skip means pause” is an unsafe assumption about program semantics. It does not claim that every native timer catches up in the same way. Verify the implementation's clock, call and resumption behaviour before relying on it.

For ordinary learning exercises, call the state update consistently and supply an explicit input. When conditional execution is required, add interruption and resumption cases to the test plan. A screenshot taken only while the routine is running cannot prove what happened during skipped calls.

Measure deadlines at actual evaluation times

A preset describes a timing requirement inside an implementation. It does not guarantee that an arbitrary program, browser or physical output updates at the exact mathematical deadline.

For a one-second delay starting at zero, compare evaluations at 0, 400, 999 and 1,007 ms. The model's Q values are false, false, false and true. The deadline is 1,000 ms, but the first observed completed result is seven milliseconds later.

Changing the preset to a convenient multiple of a nominal scan interval does not by itself prove precise timing. You still need to know the actual evaluation schedule, what clock the timer uses and how the result reaches its consumer.

Very short and zero presets deserve specific tests. The Schneider TON page cited above includes a particular note about zero or sub-cycle presets and when Q becomes true. Do not extrapolate one mathematical comparison into a universal zero-preset behaviour across libraries.

Our supplied-time examples use positive presets, fixed during the interval. They exclude clock rollover, decreasing timestamps and invalid presets. Those exclusions are visible so a reviewer knows what further tests are needed for a different environment.

04

Separate requested preset changes from the active interval

A live preset edit is a requirement change that needs a policy. Decide whether it should affect an interval already in progress, be accepted for the next interval or force an explicit restart. Then check whether the selected instruction directly supports the intended behaviour.

For a classroom configuration exercise, use the following explicit policy: accept a positive requested preset at the start of a new interval, copy it to ActivePreset and retain that value until the input becomes false. Mid-interval requests do not change the active deadline.

Start at zero with requested preset 2,000 ms. At 1,000 ms, request 500 ms while the input remains true. The active preset remains 2,000 ms, so Q is still false. At 2,000 ms Q becomes true. Clear the input at 2,100 ms, then start again at 2,200 ms with the requested 500 ms. The new interval completes at 2,700 ms.

That example is a wrapper policy for supplied configuration, not a claim about changing PT directly on every native timer. The distinction between RequestedPreset and ActivePreset makes the decision reviewable.

An implementation must also define how an invalid request is reported and whether a previously accepted configuration remains available. Keep that question separate from the fixed positive-preset timing tests. Do not silently coerce an invalid value into a different duration without an agreed rule.

In a course assessment, give the student both policies—immediate change and next-interval change—and ask which expected table belongs to each. The comparison tests whether the student understands the requirement rather than merely recognising the instruction block.

Treat reset and restart as different lifecycle questions

A false TON input can clear its active interval under the documented contract. That says nothing by itself about warm restart, cold restart, online change or download behaviour. Those events can affect instance memory through different mechanisms.

A retentive elapsed-time requirement is separate again. It may need to preserve accumulated enabled time across false inputs while allowing an explicit reset. Whether that accumulated value survives a controller restart depends on its storage and lifecycle configuration.

For a learning project, document the initial values and how a new experiment is started. If restarting the experiment clears the instance, say so. Do not label that action a realistic power-recovery test unless the relevant state, restart path and target behaviour have actually been represented.

The batch-mixer exercise illustrates a distinct retained-time model through pause and resume. Its accumulated time belongs to the virtual mixing command, not to a claim that a physical process has achieved a validated result.

Never infer equipment readiness from an elapsed preset alone. A timer can establish that its software condition has persisted according to the model; it cannot establish lubrication, cooling, pressure, motion or product quality without the necessary process evidence.

05

Keep a cross-vendor comparison specific

When moving between environments, compare complete contracts rather than block names. Record input and output types, time units, state storage, call conditions, reset behaviour, supported languages and the effect of configuration changes.

CODESYS documents TON with named IN and PT inputs and Q and ET outputs. That reference can guide a CODESYS Standard-library exercise. It is not evidence that every controller accepting structured text implements the same library or every extension to its syntax.

A vendor may offer timer instructions with register members, a different time type or language-specific availability. Compare the actual version's documentation before converting member names or copying a numeric preset. Five seconds is a duration; a bare value of five acquires meaning only from its operand contract.

Use the Siemens training hub and Allen-Bradley training hub to choose the relevant platform context. This reference deliberately avoids claiming that every Siemens timer requires one particular database arrangement or that all Rockwell timer families have identical operands.

A useful migration worksheet has one row per behaviour you depend on. Include true input, false input, exact deadline, skipped execution, restart and preset editing. Mark each as verified, different or still unknown. Unknown is a useful result because it identifies the next documentation or test task.

Build a timer integration test record

Start with a fixed preset and a simple Boolean source. Record the input, call occurrence, timestamp, Q before the call, Q after the call and the consumer's final command. These columns expose whether a discrepancy originates in the timer or in surrounding logic.

Then add one integration change at a time. Move a reader before the call, introduce a second caller, skip one evaluation or change a requested preset. Predict the new result before executing the test.

For each case, preserve the instruction version, instance identity and initialisation procedure. A trace without the initial state may not be reproducible. A trace without call occurrence may hide the difference between an executed false input and an omitted call.

Include the smallest input sequence that exposes a faulty design. For the shared-instance example, two calls with different inputs are enough. For a reader-order error, one evaluation at completion and one at reset expose both directions of the stale read.

The PLC troubleshooting guide provides a broader structure for investigating symptoms. Keep the evidence close to the requirement: what was expected, what was observed and which specific assumption explains the difference?

Use software practice to inspect the result, not to infer hardware timing

Explore the PLC timer learning examples when selecting a practice environment. Confirm the supported timer representation and inspection controls before assuming that a vendor instruction or arbitrary pseudocode can run unchanged.

For execution-order study, the scan-cycle highlighting feature is a relevant companion. Connect the highlighted evaluation with a record of values before and after the call.

These product links do not promise a free prebuilt version of every example, a hardware watchdog emulator or a specific qualification. Choose the access level and environment based on the features actually available for the intended exercise.

Save a portfolio record with the seven-row reader-order trace, the three-row instance comparison and the skipped-call comparison. Add your own observed results and explain which runtime was used. The worked values on this page were checked in independent software models, not on every supported PLC family.

06

Questions for South African PLC course learners

When comparing timer instruction training in Johannesburg, Pretoria, Durban, Cape Town or another South African location, ask which exact controller or simulator the practical work uses. Confirm the venue, software version and whether you can inspect instance state yourself.

For an online course, ask how an instructor reviews a timing discrepancy. A useful answer should include the input sequence, calling conditions and observed values, rather than only a screenshot of the final lamp. The online PLC training guide helps organise those access and assessment questions.

Can I read a timer output immediately after its function-block call?

In the ordered model shown here, the read after the call sees the updated value. A read before the call sees the stored earlier value. Check the actual environment's semantics, but do not assume that dotted output access inherently waits for another scan.

Why does one timer never finish when two conditions use it?

The calls may be sharing one stored history. In the worked example, a false second call resets the interval started by the true first call on every evaluation. Give independent timing requirements appropriate independent state.

Does skipping a timer call freeze elapsed time?

Not necessarily. Stored outputs may remain unchanged during the skipped call, while the implementation's time source continues. The resumed behaviour must be checked. Our timestamp model catches up, whereas an executed false input resets its interval.

Should a preset always be a multiple of the scan time?

That arithmetic alone does not establish correct timing. Specify the required behaviour and inspect actual evaluation times, instruction resolution and output consumption. Very short presets need explicit vendor-specific boundary tests.

How do I prove the reference example works in my project?

Reproduce the defined initial state and input sequence, record before-and-after values at each call and compare them with the expected trace. Document any changed assumptions. A passing result supports that tested configuration and sequence; it does not prove untested hardware behaviour or every possible integration.