CODESYS PLC: which controllers run it, and what breaks when you change brands

A controller dies, the replacement is months out, and somebody in the room says it: it's a CODESYS PLC, any CODESYS PLC will do. Sometimes that's true and the swap takes an afternoon. Other times it eats a week, and the code was never the problem. The hours go into four things that don't travel with the project: the device description, the firmware, the vendor libraries and the license. Here's how each of those behaves, brand by brand, and what I check before anyone orders the replacement.

What makes a controller a CODESYS PLC

Two pieces of software. The development system runs on your laptop, an IEC 61131-3 IDE that's free to download. The runtime sits on the controller and executes whatever you compile. Device makers pay CODESYS per device for that runtime and write the glue to their own hardware. More than 500 of them do, on about 1,000 device types.

So a CODESYS PLC is any controller running that runtime, whatever logo is on the front.

What changes from brand to brand is the tool. Some vendors hand you a device description for the standard CODESYS Development System and stop there. That's native. Others wrap CODESYS in their own IDE with their own name, libraries and dialogs, and people call that rebranded. Rebranded isn't worse. Your project just lives inside that vendor's tool, and getting it back out is the expensive part.

Which brands run CODESYS, and in which software

The ones I run into most:

Where each CODESYS PLC family gets programmed, and the catch on each.

ABB, Turck, ifm, Lenze, Beijer and AutomationDirect build CODESYS devices too, along with dozens of smaller names. Siemens S7 and Allen-Bradley Logix controllers run their own runtimes, not CODESYS. Beckhoff TwinCAT and B&R Automation Studio get lumped in with CODESYS a lot. I plan any swap involving them as a separate platform.

What moves between two CODESYS PLCs, and what stays behind

Say a Turck controller programmed in plain CODESYS V3.5 dies, there's a long lead time on a new one, and a Schneider M251, another CODESYS PLC, is sitting on the shelf. The POUs, global variable lists and data types copy across into Machine Expert, and most of it compiles without a touch. On a simple machine the rewiring takes longer than the software. Structured text pastes straight in. Ladder and FBD can go through a PLCopenXML export and import, which covers only a subset of a project, so check every POU afterwards.

What crosses over when a project moves to another CODESYS PLC, and what gets rebuilt on the new hardware.

Then come the exceptions. Every vendor ships its own libraries for its I/O and fieldbus extras, and none of them exist on the other brand. The device tree doesn't move either: I/O configuration and fieldbus settings get set up again from scratch. Motion works the same way. PLCopen motion calls move with the code, but the axes get set up again, and SoftMotion needs a license of its own on the new device.

That's why I keep everything hardware-specific in one program. It maps physical channels onto internal variables, and the machine logic only ever touches the internals. On a swap that one program gets rewritten. The rest is copy and paste.

A project built in CODESYS V2.3 is a different case. V3 opens it through the V2.3 converter, but the device configuration has to be recreated on the new controller.

Update Device does the retarget

Inside the project, moving to a different CODESYS PLC is one command. Install the new device description first, through Tools > Device Repository, then right-click the controller in the device tree, pick Update Device and choose the new one. The device name stays. Keep the same device type and the configuration under it stays as well. Change the type and CODESYS lists the inconsistencies on the next build. Libraries the old device pulled in don't get removed, so go through the Library Manager by hand.

If the login to the new controller is rejected, check the device description first. A description newer than the controller's runtime is not accepted. That's a description problem, not a code problem. Install the description that matches the controller's firmware and run Update Device again.

Before any of that, pin the compiler version in the project settings and the library versions in the Library Manager. Then carry the project over as a project archive with its device descriptions and libraries inside. A bare project file opened on another PC is the usual start of a missing-library hunt.

On a PFC200, the firmware picks your software

A 750-8202 and a 750-8212 look like the same controller. The 8202 is a first-generation PFC200. The 8212 is the second generation, and that one digit decides which software you'll be living in.

Two PFC200 generations and three programming tools. On the 750-8212, firmware 23 is the cutoff.

On the 750-8212, anything up to firmware 22 runs WAGO-I/O-PRO V2.3, which is CODESYS 2.3 underneath, or e!COCKPIT, which is built on CODESYS V3. From firmware 23 on it's CODESYS V3.5 and nothing else. The CODESYS 2.3 runtime is gone from the platform, and e!COCKPIT can't program it. WAGO discontinued e!COCKPIT altogether. Last orders were December 31, 2023, and support ended March 31, 2025.

The 750-8202 isn't on the firmware 23 line. It programs in WAGO-I/O-PRO V2.3 or e!COCKPIT, and CODESYS V3.5 only goes on it if you replace WAGO's runtime with a separate CODESYS runtime that needs its own license.

So the first question on a PFC200 swap is what the old project was built in. An I/O-PRO 2.3 or e!COCKPIT project needs a unit on firmware 22 or older. Drop a new-firmware 8212 in its place and you're migrating, planned or not. Coming from e!COCKPIT, the migration to V3.5 starts with e!COCKPIT 1.11 and a project on firmware 22. The migrated project gets its functional test on firmware 23, and there's no direct jump from 22 to 24, so confirm the migration on 23 before going to anything newer.

Once you're on 3.5, firmware, CODESYS version and device description have to line up:

Firmware 27 and 28 use the same CODESYS version and the same device description line, so one install covers both. Schneider's rule for Machine Expert shows how strict this pairing can be: the first two digits of controller firmware and device description must be identical, the third digit on the controller has to be equal or higher, and the fourth doesn't matter.

The license stays with the hardware

The development system is free. After that, it depends on the device, and every CODESYS PLC carries a runtime license somewhere, even when nobody ever sees it.

On a branded controller that base license is the maker's business. Add-ons aren't. A 750-8212 needs separate licenses for BACnet/IP and for the telecontrol protocols, IEC 60870, IEC 61850 and DNP3, and whatever the old machine used lived on the old unit. Ask whether it's on the new one. Same question for the base runtime when the controller doesn't come straight from the manufacturer.

A SoftPLC is stricter. On a PC, a Raspberry Pi or a CODESYS Control SL runtime on someone else's hardware, no license means demo mode, and the runtime shuts itself off after two hours.

 

Cloning is the one that catches people. Copy the SD card or system image from a licensed controller onto a second one and the license stays behind, because a software-container license is locked to the device it was activated on. The copy boots and then drops into demo mode. On Linux targets the license container sits in a hidden folder under /var/opt/codesys (.cmact_licenses on runtime 4.2.0.0 and newer, cmact_licenses on older ones). Don't delete it on a hunch: ask the device maker or CODESYS Support how to clear a cloned license. For anything that runs 24/7, I'd put the license on a CODESYS Key from day one.

The first download on the new hardware

A retarget isn't an online change. Anything that touches the device tree, Update Device included, needs a full download to the new CODESYS PLC, and the application stops while it loads. Plan the downtime.

That download reinitializes RETAIN variables. PERSISTENT ones survive it as long as the persistent variable list stays the same or is only extended. On a dead controller none of it comes along anyway, so if the old unit still boots, read the counters and recipe values out first.

Pointers bite later, once online changes start. A pointer keeps its value from the last cycle, and if its target moved in the change, it reads the wrong thing. Assign pointers every cycle instead of once at startup.

And the upload you're used to from other platforms isn't a given. File > Source Upload only works if the project was set up to put its source archive on the controller. Nobody did that? Then the controller holds compiled code and nothing you can open. I turn source download on for every project I hand over.

Before you order a replacement CODESYS PLC

 

What people ask me about CODESYS

Which PLC brands use CODESYS?

More than 500 manufacturers. The ones you'll meet most are WAGO, Schneider Electric with the Modicon M241, M251 and M262, Bosch Rexroth ctrlX, Eaton XV and XC, Festo, Weidmüller, ABB, Turck, ifm and Lenze. Siemens S7 and Rockwell Logix controllers stay on their own software..

Is a CODESYS PLC free to program?

The CODESYS Development System is a free download. Some brands charge for their own CODESYS-based IDE, Eaton among them. The runtime is the other half: a SoftPLC without a license stops after two hours, and add-on protocols can need licenses of their own.

Can I move a program from one CODESYS PLC to another brand?

The application code, usually, if both sides are on V3 and the code stays away from vendor libraries. Device description, I/O configuration, fieldbus setup and licenses get redone on the new hardware.

What language is used in CODESYS?

All the IEC 61131-3 languages: ladder, function block diagram, structured text, sequential function chart and instruction list, plus continuous function chart. V3 adds object-oriented extensions such as methods and interfaces. Structured text is where most of the portable code ends up.

Getting a CODESYS PLC back on the rail

When the code is fine and the hardware isn't, the fastest fix is still the same catalog number on firmware that matches the project. We keep both PFC200 generations on the shelf, the 750-8212 and the 750-8202, plus Schneider's Machine Expert controllers: the M241 TM241CE24R, TM241CE40R and TM241CE24T, the M251 TM251MESE and the M262 TM262L10MESE8T. All new surplus in the original box, with a 2-year warranty. Not sure which one your project needs? Tell us what's on the old unit's nameplate and what the project was built in, and we'll check.