Portable IEC 61131-3 code: moving logic between Siemens, Beckhoff and CODESYS without surprises

Portable IEC 61131-3 code is control logic written so that it can move between Siemens TIA Portal, Beckhoff TwinCAT and CODESYS with a known, small amount of rework. The standard makes the languages portable; it does not make projects portable. IEC 61131-3 reached its fourth edition on 22 May 2025, adding UTF-8 strings and a list of features added, removed or deprecated since 2013 (IEC), but no edition has ever promised that one vendor's project opens in another vendor's tool.

For a German machine builder this is a commercial question as much as a technical one. The same capping station may ship on an S7-1500 for a customer in Bavaria, on TwinCAT for a customer who standardised on Beckhoff, and on a CODESYS-based controller for an OEM partner abroad. Every time the logic is rewritten by hand, bugs that were fixed once come back. This guide covers what really moves, the exchange format that helps, the design rules that make the difference, and how the LADX Convert tool fits.

What portable IEC 61131-3 code actually means

Split every program into the part that describes the machine's behaviour and the part that talks to hardware. The first part travels well. The second part almost never does, and it is usually where most commissioning time goes.

LADX's own article on CODESYS makes the same point bluntly: the language ports, function blocks port and structure ports, while I/O configuration, motion libraries, communication blocks and fieldbus set-up do not (LADX). "IEC 61131-3 compliant" describes the language, not interchangeability of projects.

The exchange format: PLCopen XML

PLCopen's TC6 working group defined XML formats for IEC 61131-3 so that programs, including the graphical layout of ladder and function block networks, can be exchanged between tools. The current PLCopen specification is version 2.01, and in 2019 it became part of the IEC 61131 series as IEC 61131-10 (PLCopen).

Support is real but partial. CODESYS has an Import PLCopenXML command that lists the objects in a file and lets you choose what to bring in (CODESYS help). Beckhoff documents PLCopen XML export and import for TwinCAT 3 and states plainly that the format is a subset of the elements TwinCAT knows, so 100% compatibility is not ensured (Beckhoff Infosys). Siemens S7-1500 projects are a different world again: Structured Text arrives there as SCL, Siemens's dialect, with its own block types and system functions.

Design rules for logic that travels

1. Put a hardware layer between the logic and the I/O. Map physical inputs and outputs into a structure at the start and end of the cycle. The machine logic reads and writes the structure, never an address.
2. Write behaviour in Structured Text or plain ladder. Avoid vendor-only instructions in core function blocks. If you need one, wrap it in a small block that you replace per platform.
3. Own your timers. Rockwell timer structures and IEC timer blocks behave differently on reset and hold different state. Use IEC TON/TOF semantics consistently and test the reset path.
4. Declare data types with explicit widths. INT, DINT and REAL overflow differently than people assume. A counter that wraps on one platform and faults on another is a classic migration bug.
5. Model sequences as a state machine. One integer state, one transition per rung or CASE branch. It is easier to move than SFC, where step and action handling differ between tools.
6. Adopt one naming convention. The PLCopen Coding Guidelines, released in 2016, are a reasonable neutral starting point (PLCopen).
7. Keep test vectors with the code. A list of input sequences and expected outputs is the only honest proof that the program on platform B behaves like the program on platform A.

These rules also make the code easier to keep under version control. Our guide to PLC version control with Git shows which platforms export clean text and which do not.

Where LADX Convert fits

LADX is an AI workbench for automation engineers, built for people who work across a Siemens line, a Rockwell cell and a CODESYS skid in the same week. Its Convert tool takes a program drawn or saved in LADX and writes it out as IEC 61131-3 Structured Text, Siemens SCL, Rockwell neutral text or PLCopen XML (LADX Convert).

How it works, step by step:

1. The program is held in one intermediate representation built on PLCopen TC6, not converted brand to brand.
2. You choose a target: Structured Text, SCL, Rockwell neutral text or PLCopen XML. All four are written from the same source, so they cannot drift apart.
3. Every element in the output is marked as converted cleanly, converted with a semantic difference worth reading, or needing a decision.
4. Anything unmapped stays as an annotated placeholder rather than being dropped or silently reinterpreted.
5. The conversion runs in the browser. Nothing is uploaded, which matters when the program belongs to your customer.

What it does not do is just as important. Reading vendor projects back in is, in LADX's own words, the half that is not built yet, so today you convert programs that live in LADX rather than importing a TIA Portal archive. Bridged rungs, where a wire crosses between parallel branches, are refused and preserved rather than approximated. Whole-project formats such as .ACD and .ap1x need a desktop bridge and your own licensed IDE. And LADX never writes to a live controller.

A realistic workflow for a machine builder

Take a packaging machine builder that keeps its reference program in Structured Text and ships on TwinCAT by default. A customer now insists on an S7-1500. A workable sequence looks like this:

1. Freeze the reference version and its test vectors.
2. Generate the SCL version of the machine logic, and read the conversion report line by line.
3. Rebuild the hardware layer, safety program and drive integration natively in TIA Portal. Do not try to convert these.
4. Run the same test vectors against both versions, ideally against a simulated machine, and compare outputs rather than code.
5. Document every place where behaviour had to differ, so the next variant starts from a known list.

The test step is where most of the value sits. LADX's article on cross-vendor migration puts it well: verify by comparing behaviour, not code (LADX). If you already run virtual commissioning with PLCSIM Advanced or TwinCAT, the same machine model can serve both platforms.

Where Wartens fits

Wartens writes PLC software for German machine builders in TIA Portal, TwinCAT and CODESYS to IEC 61131-3. If you need a second platform variant of an existing machine, or want your reference code restructured so it moves more easily, see our automation engineering services or the digital twin and virtual commissioning service for the test bench.

Next step: send us one representative program and the target platform. We will tell you which parts will port, which must be re-engineered and how we would prove equivalence. Contact us.