A timeout and a process duration may use the same timer instruction while expressing different promises. “Mix for twenty seconds” defines intended work. “The valve must prove open within two seconds” bounds missing evidence. The first may permit a normal transition; the second usually identifies an abnormal result. Name the timer for its job, and state what happens when it completes.
Ask what the duration means before choosing a timer
“Add a timer” can mean several different things. You may need a signal to remain true for a minimum duration, keep a fan running after demand ends, generate a fixed pulse, or detect that an expected event never arrived. Those are different behaviours. Choose the behaviour first and the function block second.
For our carton cell, arrival supervision asks: while seeking a carton, how long have we waited without confirmed arrival? It does not ask how long the PLC has been in RUN, or how many scans have passed since the operator opened the page. The timer input must express the interval you intend to measure.
TON qualifies a continuously true condition
A typical TON delays its done output until its input has remained true for the preset interval. Removing the input resets the timing interval and the done output. Beckhoff's documented TON interface uses IN, PT, Q, and ET; its false-input behaviour clears Q and elapsed time. Beckhoff TON reference.
In the following excerpt, ArrivalTimer is a persistent instance declared as TON. Call it once on every invocation of the owning cyclic task, including when the station is not seeking.
WaitingForArrival := (State = STATE_SEEKING) AND NOT CartonAtFill;
ArrivalTimer(IN := WaitingForArrival, PT := ArrivalLimit);
ArrivalTimeout := ArrivalTimer.Q;When the machine leaves Seeking, WaitingForArrival becomes false, and the call resets the ordinary non-retentive timing interval. If the state transitions elsewhere need the timer output from this invocation, call the block before evaluating those transitions.
Decide explicitly how simultaneous arrival and expiry are resolved. In this example, observing arrival makes the timer input false and normal arrival wins. A process requiring timestamp-based deadline enforcement needs a more precise acquisition and comparison design.
Draw a time trace instead of guessing
Suppose a teaching TON has a 300 ms preset. Its input becomes true at a call designated time zero. Calls occur every 100 ms, and the input goes false at the 200 ms call.
| Call time | Input | Elapsed interval after call | Done output |
|---|---|---|---|
| 0 ms | True | 0 ms | False |
| 100 ms | True | 100 ms | False |
| 200 ms | False | 0 ms | False |
| 300 ms | True | 0 ms | False |
| 400 ms | True | 100 ms | False |
| 500 ms | True | 200 ms | False |
| 600 ms | True | 300 ms | True |
The first 200 ms did not accumulate toward the second attempt. That is why TON is useful for a condition that must remain continuously true. It is not automatically a total operating-hours accumulator.
Actual timer resolution, call scheduling, and time-base implementation depend on the runtime. Observe Q only when the block is evaluated and the consuming logic runs. Do not promise sub-task-interval reaction merely because the preset has millisecond units.
TOF and TP answer different questions
An off-delay timer keeps its output true for a configured interval after its input becomes false, provided it was previously activated. That can model a teaching extraction fan's post-run demand. It is not a delayed start. Check how reasserting the input cancels or restarts the off-delay in the chosen library. Beckhoff TOF reference.
A pulse timer produces a timed output in response to an accepted input transition. Unlike TON, its purpose is a pulse duration, not proof that the input remained continuously true. Retriggering and parameter changes during a pulse deserve explicit review against the target's documented implementation. Beckhoff standard-library timer documentation.
Do not connect a pulse timer directly to a motion command and assume Stop will cancel it. If the chosen block continues its pulse after the trigger disappears, the output arbitration still needs the required stop and permissive behaviour. The timer is one source of demand, not the final authority over an actuator.
The instance is the stopwatch
TON is a block type; ArrivalTimer is a particular timer with its own state. Two independent intervals need independent instances unless the design intentionally shares one interval. Reusing one instance for arrival supervision and discharge supervision in the same invocation overwrites its inputs and makes the time history difficult to reason about.
The opposite mistake is recreating temporary timer state on each call so it never remembers progress. Declare the instance in persistent program or function-block storage according to the target environment. Then call it consistently.
A common broken pattern calls the timer only inside the state that uses it. On leaving the state, no false-input call occurs. When the state is entered again, old internal state or outputs may influence the result. Calculate the enable condition from the state, but keep the timer's lifecycle visible outside the conditional branch.
Timeouts diagnose an unmet expectation
An arrival timeout proves that arrival was not observed in the allowed interval. It does not prove that the motor failed. The carton may be missing, the belt may slip, or the sensor may be misaligned. Name the diagnostic after the unmet expectation and preserve relevant evidence: state, command, feedback, elapsed time, and recent transitions.
Choose timeout values from the process. If a carton travels 1.2 m at a guaranteed minimum transport speed of 0.3 m/s, ideal travel alone takes 4 seconds. Acceleration, sensor placement, product slip, and scheduling add uncertainty. A 2-second timeout would be inconsistent with those assumptions before any code runs.
Do not cure repeated timeouts by increasing the limit without investigation. A rising arrival duration may reveal a mechanical or process change. Trend the interval when it provides useful diagnostic evidence.
Try it
A pressure indication flickers true for 40 ms, false for 20 ms, then true for 200 ms. The contract requires 100 ms of continuous adequate pressure before accepting a new cycle. Once a cycle runs, loss of pressure must be evaluated under a separate interruption rule.
Choose a timer behaviour and explain whether the first 40 ms contributes to the later qualification. Then explain why the timer's done output should not be treated as proof of current pressure after the raw indication is lost.
Work through the answer
Use a continuously called TON driven by the adequate-pressure indication, with a 100 ms preset for the model. The false interval resets qualification, so the first 40 ms does not contribute. The later true interval can qualify after 100 ms, subject to task sampling and the chosen timer implementation.
Use the qualified condition for the specific purpose of accepting a new cycle. Define ongoing pressure supervision separately. A delayed or retained qualification signal can hide current loss if it is reused carelessly. With a normal TON called on each invocation, Q resets when false is observed, but the process response still needs its own explicit rule and appropriate acquisition timing.
Next, counting events replaces “how long?” with “how many?” The same questions about sampling, ownership, and reset will return in a different form.