CODESYS Platform · 02
CODESYS Control Runtime: the layer that runs your application in the field
The development environment produces the program; the runtime executes it inside the machine, cycle by cycle. Whether a machine runs steadily usually comes down to how this layer was set up.
It is the worst cycle that matters, not the average
When people discuss cycle time they usually quote the average. But what produces the error in the field is not the average — it is the worst-case deviation. If nine hundred and ninety-nine cycles out of a thousand finish in 250 µs and one takes 3 ms, on synchronised axes that single cycle shows up in the product as a cutting error.
That is why we record jitter during commissioning and write the acceptance criterion against the worst cycle rather than the mean.
- Task separation Motion, logic and communication are split into separate tasks with separate cycle times, so slow work never blocks the fast cycle.
- Core isolation The control task runs on its own core, where operating-system work cannot disturb its timing.
- BIOS preparation Power saving and frequency scaling are switched off so that latency becomes stable.
- Measurement and record Jitter is measured under load and the figures are written into the handover file.
Choosing an edition
One question is usually enough: do the axes on your machine need to be locked to each other? If they do, you want the real-time edition; if they do not, the standard edition will normally do.
| Property | Standard (Windows) | Real-time | Linux / embedded |
|---|---|---|---|
| Timing source | Operating system | Its own core | With PREEMPT-RT |
| Typical minimum cycle | ~10 ms | 250 µs | 1 ms |
| Synchronised axes | Not recommended | Suitable | Hardware dependent |
| Distributed clock (EtherCAT) | Unstable | Full support | Supported |
| Unit hardware cost | Low | Medium | Low |
| Typical use | Testing, training, simulation | Motion, CNC, multi-axis lines | Series products, data collection |
A common mistake
Treating a result obtained with the standard edition on a prototype as valid for series production. An application that looks flawless with one axis on the test bench behaves quite differently once six axes are synchronised and jitter enters the picture. Building the architecture for the target edition from the start is cheaper than backtracking.
For the effect on the fieldbus side, see the Fieldbus & Communication page.
Frequently asked questions about the runtime
Do I need special hardware for real-time operation?
What decides the outcome is not processor speed but how stable the interrupt latency is. On office-class machines, power management and background services make the cycle time fluctuate. Where synchronised axes are expected, we recommend a fanless industrial PC with power saving disabled in the BIOS.
Is real-time possible on Windows?
The standard edition runs as an ordinary Windows application; its timing depends on the operating system and it suits testing, training and low-precision work. The real-time edition takes a processor core away from the operating system and runs on its own scheduler.
Can I move the same application to an embedded board?
Yes. The application logic carries over; only the device description and I/O mapping are reconfigured for the target. That is what lets you prototype on a desktop and move to an ARM board for series production.
Why does jitter matter so much?
Because the error comes from the worst cycle, not the average. On two synchronised axes, a single cycle of delay shows up directly in the product as a position difference. That is why we write the acceptance criterion against worst-case jitter measured under load, not the mean.
What happens to the machine if the runtime stops?
A controlled stop is the responsibility of the safety chain, not the application. Safety relays and a certified safety controller operate independently of the control application, so the drives go to a safe state when the software stops. On the application side, the watchdog and restart behaviour are defined at the start of the project.
How many axes can one controller manage?
The limit is set by the cycle budget, not the licence: axis count multiplied by the computation per axis has to fit inside the target cycle. Managing dozens of axes at a 250-microsecond cycle is routine on a mid-range industrial PC. The exact figure depends on axis type and kinematic complexity.
How do you update the application in the field?
By downloading over the network; there is no need to open the cabinet. Before the update the current version is backed up and its tag recorded. With that in place, rolling back if something goes wrong takes minutes.
Is the licence tied to the hardware?
There are two options: a hardware dongle or a software container bound to the target device. A dongle makes swapping devices easy; a container has no physical part to lose and is more practical in series production. The choice follows your service model.
Is the Linux edition slower than the Windows one?
No — it can be the other way around. With a real-time patched Linux kernel, going below one millisecond is routine and the hardware cost is low. What matters is not the operating system brand but the kernel’s real-time configuration and the quality of the device drivers.
How do we know whether our existing hardware is enough?
By measuring. We run a representative load on the target hardware and record the jitter, then judge the result against your target cycle time. It is a day’s work, and negligible next to the cost of starting out on the wrong hardware.