TIA Portal vs CODESYS vs SIMATIC AX vs ?

October 30, 2026 · otomakeit-oracletia-portalcodesyssimatic-axplc-programmingcontrol-systems

Does it matter anymore?

At my previous employer, every design process was built around Siemens equipment. That made sense. It is hard to keep company workflows running in parallel for several hardware platforms, so you pick one and build everything on it.

Don’t get me wrong: I’m a huge fan of Siemens hardware. It’s one of the best in automation, maybe the best. But being locked to one hardware provider is not a good idea. COVID-19 proved it. Supply chains broke, Siemens and everyone else. If I could have switched platforms freely, that period would have been much easier.

I think this problem can be solved soon. At least, that’s what I’m working on.

Control program connectors

In my last article I showed Oracle’s ECAD connectors: one design model, delivered as EPLAN, AutoCAD Electrical or Oracle’s own drawings. The next direction is now in the build stage: control program connectors.

TIA Portal connector
SIMATIC AX connector
CODESYS connector

The idea is the same. The model is the master. It holds the PLC hardware with rack and slot, the tag list with addresses, the data types, the function blocks with their interfaces and logic, and the test cases. A connector compiles that into a native project in the selected software, the way that tool expects it.

The slides show the same test project as last time, the tank pump panel, in all three tools: project tree, hardware, tag table and the same function block.

Project tree in TIA Portal, CODESYS and SIMATIC AX: the same blocks, types and tags, each organised the way its own tool expects

The 14 PLC tags in TIA Portal, CODESYS and SIMATIC AX, with the same symbols and comments from one tag list in the model

FB_ModeManager in TIA Portal, CODESYS and SIMATIC AX, written by each connector from one model body

Every tool has its quirks

Every tool has its quirks, and the connector handles them. One example: convert 2.5 from REAL to INT. TIA Portal and SIMATIC AX give 2, CODESYS gives 3. Same code, different result. So the model uses one explicit rounding function, and each connector writes it so all three give the same answer.

Implicit REAL to INT conversion of 2.5 and -2.5 in TIA Portal, CODESYS and SIMATIC AX, and the model’s explicit rounding function

How do I know the projects match the model?

Each one compiles with 0 errors and 0 warnings.
For TIA Portal and CODESYS, the connector reads the block interfaces back from the tool and compares them with the model.
The same 14 test cases run in every tool: on PLCSIM Advanced for TIA Portal, as unit tests in SIMATIC AX, and in CODESYS simulation. All 14 pass in all three.

Compile results, comparison with the model and 14 of 14 tests passed in each tool

And the supply-chain question?

CODESYS can’t run a Siemens CPU. So the CODESYS project comes from a variant of the tank model: a WAGO PFC200 with WAGO I/O and a Weintek panel instead of the S7-1200 and the Siemens HMI. The program, the safety circuit, the drive wiring and the field terminals stay identical. The drawings are regenerated for the new hardware. Changing the PLC vendor becomes a declared change to the model, not a redesign.

What changed in the WAGO variant of the tank model and what stayed identical

Still ahead: HMI screens from the model, and running on real hardware.

The PLC software doesn’t go away. It becomes a delivery format, chosen per project, instead of a decision locked in years ago by the workflow.

The model is the master. The PLC tool is the delivery format.

All the comparisons, including the main program and the hardware configuration, are in the full slide set: download the PDF (11 pages, 1.7 MB). The other Oracle articles are collected on the Otomakeit Oracle page.