How is timing and scheduling done in CoDeSys?

How are timing and task scheduling configured in CODESYS?

Separate the waiting period from the program’s execution rhythm

Hello everyone. Timing in CODESYS addresses two different needs: delaying an action and deciding when programs execute. TON, TOF and TP address the first; Task Configuration addresses the second. In the IEC 61131-3 programming model, a timer updates its state when called instead of suspending the task while it waits. This guide covers CODESYS V3.

1. Configure the task cycle

In your project, open Task Configuration below Application. Select MainTask or another task, choose Type: Cyclic and enter a value such as T#10ms in Interval. Use Add Call to add the PROGRAM to execute. Multiple program calls execute from top to bottom; function blocks are called from those programs.

10 ms is the target repetition interval, not a requirement for the program to spend 10 ms executing. Assess whether the PLC program can finish within that interval. Include controller capacity, I/O updates and communication load in the assessment. The software’s task tools do not remove the hardware’s physical limitations.

2. Select the appropriate task type

Cyclic repeats at configured intervals. Event is triggered when its BOOL event variable changes from FALSE to TRUE. Status is eligible to run while its condition is TRUE; the task can clear the flag when only one operation is required. Freewheeling has no configured fixed cycle interval. Event and Status are different behaviours. A short event pulse can be missed between scheduler checks. Freewheeling is unsuitable for a fieldbus task requiring a fixed cycle.

3. Balance priorities and processing load

In the CODESYS task settings, 0 is the highest priority; larger numbers indicate lower priorities. On the same processor core, a higher-priority task can interrupt a lower-priority one. Multicore execution also depends on task allocation and the operating system. Giving every task the highest priority is not a solution.

Different automation functions need not all run at the same rate. For example, consider separate tasks at 10 ms for machine sequencing, 100 ms for slow process evaluation and 1 s for statistics. These are illustrative starting points; select actual values through measurement. Avoid writing the same output from several tasks and coordinate access to shared data.

4. What do TON, TOF and TP do?

The basic behaviour of these blocks is the same whether your programming language is ST, LD or FBD. Use standard timers from the appropriate Standard library in Library Manager. Declare a separate function block instance for each independent operation. IN is the condition, PT the preset duration, Q the result and ET the elapsed time. PT and ET use the TIME data type.

TON, on-delay: Q becomes TRUE after the preset time if IN remains TRUE continuously. When IN becomes FALSE, the timing state and output reset. One use is checking that a run request has remained active for 3 seconds.

TOF, off-delay: Q is TRUE while IN is TRUE. When IN becomes FALSE, the delay starts, and Q becomes FALSE when it expires. If IN returns to TRUE before expiry, the off-delay resets. A typical use is keeping a fan running briefly after a process ends.

TP, pulse timer: A rising edge at IN makes Q TRUE for the PT duration. Holding IN TRUE does not automatically generate repeated pulses. TP is not a periodic scheduler by itself. Repeated actions need a task or additional triggering logic.

5. An ST example with a three-second delay

In the following Structured Text example, PLC_PRG is called from a cyclic task, such as one running every 10 ms. The project must include the Standard library. xStartRequest represents the run request and xEnable the permissive. fbStartDelay is called every cycle, and the rest of the program continues executing during the delay.

PROGRAM PLC_PRG
VAR
    xStartRequest   : BOOL;
    xEnable         : BOOL := TRUE;
    xDelayedCommand : BOOL;
    tElapsed        : TIME;
    fbStartDelay    : TON;
END_VAR

fbStartDelay(
    IN := xStartRequest AND xEnable,
    PT := T#3s
);

xDelayedCommand := fbStartDelay.Q AND xEnable;
tElapsed := fbStartDelay.ET;

If xStartRequest and xEnable remain TRUE continuously, xDelayedCommand becomes TRUE at an appropriate call after 3 seconds have elapsed. If either condition becomes FALSE, TON resets. A momentary button pulse does not replace a continuous three-second request. If the request must remain active after the button is released, implement separate state logic with start and stop conditions.

Editor’s note: SLEEP, DELAY and WAIT are not built-in standard ST delay commands available on every CODESYS target. Some system libraries provide waiting functions, whose effect on task execution needs separate assessment. Use timers and state logic instead of holding the PLC in a waiting loop. Calling TON only when its condition is TRUE can skip the FALSE call needed to reset it.

6. Distinguish configured time from physical response

A T#10ms task interval does not guarantee that every physical event is detected within 10 ms. Input filtering, the fieldbus cycle, task start time and output transfer affect the overall response. Network settings and data exchange between devices are part of that chain. Setting T#1ms in a 10 ms task does not create a physical pulse with 1 ms accuracy.

Variation in the task interval is assessed as jitter. Very short pulses may require suitable hardware capture or a high-speed counter. Measuring a delay by adding a fixed amount every cycle can introduce timing errors when cycles take longer. Design elapsed-time measurement separately from counting executions.

7. Separate task watchdogs from process timeouts

A task watchdog monitors excessive task execution time or missed-cycle conditions supported by the target. A process timeout might instead detect a valve failing to provide feedback within 2 seconds; monitor this separately in application logic. Neither setting replaces the other. For lengthy operations, divide the work across several cycles and preserve its state for the next call.

Check watchdog duration, sensitivity and output behaviour on faults for the actual target. Investigate processing load and slow code instead of arbitrarily increasing the limit. Exceeding the task interval does not always trigger a watchdog fault; this depends on the watchdog threshold and the device’s missed-cycle behaviour.

8. Verify the timings through measurement

During debugging, inspect execution times and jitter in the Task Configuration monitoring view. Monitor the timer’s IN, PT, Q and ET; use appropriately sampled Trace recordings for short events. When transferring training examples to real hardware, repeat tests under maximum processing load, heavy communication and fault conditions. Correct timing means measuring the required response, not simply entering a duration.