Industrial controllers do not execute a PLC application as one large block. CODESYS organizes the application into devices, applications, tasks, and programs. Understanding that execution model is the starting point for building a predictable and maintainable controller.
This article is the first part of the CODESYS Advanced System Architecture & IIoT series. It focuses on runtime behavior and task scheduling.
The CODESYS execution model
At a high level, a CODESYS application moves through an initialization phase, cyclic execution, and shutdown. The application contains tasks, and each task calls one or more programs or function blocks.
Device
└── Application
├── Task Configuration
│ ├── Fast control task
│ ├── Standard logic task
│ └── Communication task
└── Programs and Function Blocks
The important design decision is not simply how often the PLC scans. It is which work belongs in which task and what timing that work requires.
Choosing a task type
| Task type | Typical use | Main consideration |
|---|---|---|
| Cyclic | Motion, control loops, repeated logic | Keep execution time below the interval |
| Event | Logic triggered by a signal or event | Avoid unpredictable event bursts |
| Freewheeling | Background or non-time-critical work | It should never delay control logic |
A temperature alarm calculation may run in a standard cyclic task. A high-speed control loop may require a shorter cycle. Logging, diagnostics, or non-critical data preparation can usually run less frequently or in a background task.
Interval is not the same as execution time
If a task interval is 10 ms, the task is scheduled every 10 ms. That does not guarantee that the application logic completes in 10 ms. The execution time must include program logic, function blocks, communication handling, and any system overhead.
Task interval: 10 ms
Execution time: 3 ms → healthy margin
Execution time: 10 ms → no margin
Execution time: 14 ms → possible overrun
Repeated overruns can cause delayed outputs, missed communication windows, watchdog events, or unstable control behavior.
What is jitter?
Jitter is the variation between the intended execution time and the actual execution time. A task that normally runs every 10 ms but occasionally starts at 12 ms or 15 ms has timing jitter.
Common causes include:
- Too much logic in a fast task
- Blocking communication calls
- Large data processing or string operations
- Excessive logging
- Competing high-priority tasks
- Poorly controlled event bursts
The right response is not always to make every task faster. It is often better to separate time-critical logic from communication, diagnostics, and data-processing workloads.
Priorities, preemption, and watchdogs
Task priorities determine which task receives CPU time when tasks compete. A high-priority task can preempt a lower-priority task, but excessive high-priority work can starve background tasks.
A watchdog provides a limit for acceptable task execution. It should be configured based on measured behavior and the required process response—not chosen as an arbitrary large number. A watchdog that is too short creates nuisance faults; one that is too long delays fault detection.
A practical review checklist
Before commissioning a CODESYS application, review:
- Which functions require deterministic timing?
- Is the measured execution time comfortably below the task interval?
- Are communication and logging separated from control logic?
- Can an event source generate a burst of work?
- Are priorities and watchdog limits documented?
- What should happen when a task overruns?
Conclusion
Stable PLC software begins with a clear execution model. By assigning the right work to cyclic, event, and background tasks—and by measuring execution time instead of guessing—engineers can reduce jitter and make later IIoT integration safer.
In the next article, we will look at RETAIN, PERSISTENT, and modular data design for applications that must survive power cycles and remain easy to maintain.