CODESYS Platform
What is CODESYS and what is it for in industrial automation?
In short: you write your control logic once and run it on any controller that supports the runtime. The longer version is below — the components, how it works, and where it genuinely differs from the classic PLC approach.
Understanding the platform in two halves
Thinking of CODESYS as a single program is what confuses people. In practice there are two separate things: the development environment on your desk and the runtime inside the machine. The first is where you write the program and it is free; the second executes that program in real time and is licensed.
- CODESYS Development System Project tree, library manager, device configurator and debugger. Breakpoints, variable watching and changing values online all happen here.
- CODESYS Control Runtime The software that executes the compiled application cycle by cycle on the target. It runs on an industrial PC, an ARM-based embedded board or a third-party controller.
- Device descriptions Files that describe what a drive, an I/O module or a controller can do. Once added to the project, the field device becomes visible in the configurator.
- Libraries Ready-made blocks for motion control, communication, file handling and maths. Your own in-house library can be versioned and distributed the same way.
Why does the standard matter so much?
IEC 61131-3 is the shared grammar of industrial control programming. Logic that one engineer writes to the standard can be read by any other engineer who knows it. On paper this looks like a compliance question; in the field it is a handover question.
A control program written in a vendor-specific language becomes hard to maintain the moment the person or company who wrote it is gone. A project tied to the standard stays readable. For the machine owner that is a concrete reduction in supplier dependency.
How it differs from the classic PLC approach
The comparison below is not a ranking. It shows which approach comes out ahead under which conditions.
| Criterion | Classic PLC | CODESYS |
|---|---|---|
| Hardware dependency | Locked to the manufacturer | Any device that supports the runtime |
| Compute capacity | Bounded by the model | Scales with processor class |
| Motion and CNC | Usually an add-on module | Same project, same cycle |
| Operator interface | Separate HMI software | One shared variable pool |
| Setup on a small machine | Fast, off-the-shelf | Needs configuration |
| Initial investment | Predictable | Varies with hardware choice |
Where should you start?
The right starting point is not the software but the machine. Axis count, whether the axes need synchronising, the target cycle time and what the operator must be able to do from the screen — once those four are clear, the required components follow on their own.
To look at the layers one by one, see Engineering, Control Runtime and SoftMotion pages.
Frequently asked questions
What is the difference between CODESYS and a PLC?
A PLC is hardware; CODESYS is the software platform you use to write the control application that runs on it. You can program a PLC with CODESYS, but you are not tied to one brand — the same application runs on any device that supports the runtime.
Is the development environment paid?
The development environment is free to download and can be tried without a licence in simulation mode. Charges apply to the runtime on the target device and to add-on packages such as SoftMotion, CNC and visualization.
Which programming languages can I use?
All six languages in the IEC 61131-3 standard: Structured Text (ST), Function Block Diagram (FBD), Ladder Diagram (LD), Sequential Function Chart (SFC), Continuous Function Chart (CFC) and Instruction List (IL). They can be mixed within one project.
Does it make sense for a small machine?
Not always. On a machine that only does logic with a handful of I/O points, a leaner configuration is often the right answer. The advantage of CODESYS grows as the axis count rises and as logic, motion and the interface need to live in one place.
How short can the cycle time be?
For logic tasks, the millisecond range is more than enough on most machines. Motion tasks can go down to 250 microseconds with a real-time kernel and suitable hardware. What decides this is not the software but the processor class and the operating-system layer, which is why we agree the target before choosing hardware.
Is the application really hardware-independent?
The logic layer is independent and carries over as-is. Device configuration, fieldbus definitions and vendor-specific function blocks are rebuilt for the new target. So migration is not zero effort — but the gap between rewriting a program and redoing a configuration is very large.
Are safety functions also written in CODESYS?
Safety logic is built on a certified safety controller as a separate safety application; it is never mixed into the standard control application. Where CODESYS Safety is used, the two applications sit in the same project tree but stay isolated from each other. The risk assessment determines what is required.
How far can I get with simulation?
The whole logic flow, alarm scenarios and the operator screen can be tested before you go to site. What simulation cannot give you is the behaviour of real mechanics: friction, inertia, material variation. So it is not the finish line — it is the preparation that shortens time on site.
Can I reuse my libraries across projects?
Yes, and this is the way we recommend working. Once your in-house library is versioned and distributed, no new machine starts from zero. Version tags also keep a record of which library release is running on which machine.
How long does it take to learn the platform?
An engineer with PLC experience becomes productive within a few days; the sticking points are usually not the language but task configuration and fieldbus setup. We run a training programme aimed squarely at those two topics — details are on the Training Request page.