Why CODESYS Is the Arduino of PLCs — And Why That Matters More Than Most Engineers Realise

There is a conversation that happens in engineering offices across the world, usually when a company is evaluating a new machine or control system. It goes something like this:

"What PLC are you using?" "Siemens." "Okay, do you have TIA Portal experience?" "No, we're a Rockwell shop." "Right. So we'll need to retrain, or hire someone."

This conversation is so normalised in industrial automation that most engineers don't even register it as a problem anymore. It's just how things are. Every vendor has their own environment. Every environment requires its own training. Your skills are tied to the hardware you learned on.

In the world of embedded microcontroller programming, this was also how things worked — until Arduino.

Understanding how Arduino changed embedded development helps explain what CODESYS has done for PLC programming, why it matters, and why the parallel between the two is more than a casual analogy.

---

Part 1: What Arduino Actually Changed

Cast your mind back to pre-Arduino embedded development. If you wanted to program an Atmel AVR microcontroller, you used AVR Studio and wrote in C with AVR-specific headers. If you wanted to program a Microchip PIC, you used MPLAB with PIC-specific libraries. ARM Cortex-M meant Keil or IAR. Each toolchain had its own syntax conventions, its own hardware abstraction layer, its own debugging workflow.

The microcontrollers themselves were often architecturally similar — all running C, all doing more or less the same things. But the tooling ecosystem around each one was isolated. Knowledge of one did not transfer cleanly to another.

Arduino introduced a universal abstraction layer. The framework wrapped the hardware-specific details behind a consistent API: digitalWrite(), analogRead(), Serial.begin(). The same sketch that blinked an LED on an Arduino Uno would run with minimal modification on an Arduino Mega, a Nano, a Due, or eventually on boards from completely different manufacturers who supported the Arduino framework.

More importantly, the IDE was accessible. One download, one interface, one community. A student who learned Arduino on an Uno could contribute to a project using a different Arduino-compatible board without starting over.

The deeper change was cultural. Arduino made embedded programming a transferable skill rather than a vendor-specific credential. The question shifted from "which microcontroller do you know?" to "can you write embedded C?"

---

Part 2: The State of PLC Programming Before CODESYS

Industrial PLC programming developed along a different trajectory — and for understandable reasons.

In the 1960s and 70s, when PLCs were first developed, the goal was to replace relay logic panels in automotive factories. The engineers operating these panels were electricians and technicians, not software developers. The first PLC programming languages — particularly Ladder Diagram — were designed to look as much like relay schematics as possible. An electrician could read Ladder and understand it because it mapped directly to the physical relay circuits they already knew.

This was genuinely clever design. It lowered the barrier to adoption enormously. Factories could deploy PLCs without retraining their entire technical staff from scratch.

But as PLCs evolved, each manufacturer built their own implementation. Siemens developed STEP 5, then STEP 7, then TIA Portal — each version adding capabilities but remaining proprietary and Siemens-specific. Allen-Bradley (now Rockwell Automation) developed PLC-5, then RSLogix, then Studio 5000. Schneider had PL7, then Unity Pro, then Machine Expert. Mitsubishi had GX Works. Omron had Sysmac Studio.

Each environment had its own:

• Variable declaration syntax
• Function block library
• Communication configuration
• Debugging and diagnostic tools
• Hardware configuration workflow

A controls engineer trained on Siemens TIA Portal could not sit down at a Rockwell machine and be productive without significant retraining. Their Ladder logic knowledge transferred — Ladder is Ladder — but everything around it did not.

The result was a skills market organised by vendor loyalty. Companies standardised on one PLC brand and stayed there, partly because switching meant retraining, partly because years of institutional code and knowledge were locked inside a proprietary environment.

---

Part 3: What CODESYS Is — And What It Isn't

CODESYS (Control Development System) was developed by 3S-Smart Software Solutions, a German company founded in 1994. The core product is a runtime engine and development environment for IEC 61131-3 compliant PLC programming.

IEC 61131-3 is the international standard that defines five programming languages for programmable controllers:

• Ladder Diagram (LD) — relay-style graphical language
• Function Block Diagram (FBD) — signal-flow graphical language
• Structured Text (ST) — high-level text language similar to Pascal
• Instruction List (IL) — low-level assembler-style language (now deprecated in newer standard versions)
• Sequential Function Chart (SFC) — state-machine graphical language

The standard defines the syntax, semantics, and data types for all five languages. It does not define the development environment, the hardware, or the runtime.

CODESYS implements this standard as a development environment (the IDE) and a runtime engine (the component that executes IEC 61131-3 programs on hardware). The critical point: CODESYS licenses its runtime to hardware manufacturers. Any manufacturer who pays the license fee and integrates the CODESYS runtime into their hardware gets a fully IEC 61131-3 compliant PLC — programmed using the standard CODESYS IDE.

This means a controls engineer using CODESYS writes the same Structured Text code regardless of whether the underlying hardware is a Beckhoff CX controller, a Wago PFC200, a Revolution Pi, an Arduino Opta, a Bosch Rexroth controller, or a Lenze i550. The IDE is the same. The debugging workflow is the same. The function block libraries are the same.

---

Part 4: The Arduino Parallel — Where It Holds and Where It Differs

The parallel between Arduino and CODESYS is instructive but not perfect. Understanding where it holds and where it diverges clarifies what CODESYS actually achieves.

Where the parallel holds

Vendor neutrality — Both Arduino and CODESYS are framework layers that run on hardware from multiple manufacturers. In both cases, the programmer learns the framework, and their skills transfer across hardware platforms that support it.

Lowering the barrier to entry — Arduino made embedded programming accessible to people who weren't microcontroller specialists. CODESYS makes industrial PLC programming accessible to any engineer who learns IEC 61131-3 — without being locked into one vendor's proprietary environment first.

Enabling new hardware entrants — Arduino allowed small hardware manufacturers to offer boards with an established, supported programming ecosystem without building one from scratch. CODESYS allows smaller industrial hardware manufacturers to compete against Siemens and Rockwell by offering a professionally credible programming environment — the Revolution Pi is the clearest example of this.

Separating the programming skill from the hardware credential — Before Arduino, "I know Atmel AVR" was a credential. After Arduino, "I know embedded C with Arduino" was a more transferable credential. Before CODESYS matured, "I know Siemens S7" was a credential. CODESYS shifts this toward "I know IEC 61131-3 Structured Text" — a skill that transfers.

Where the parallel differs

Maturity and adoption curve — Arduino went mainstream quickly because its target audience (students, makers, hobbyists) was large and adoption barriers were low. CODESYS adoption has been slower because industrial procurement decisions are conservative, and the installed base of existing proprietary PLC code creates strong inertia.

The proprietary giants didn't adopt it — Arduino's success meant that hardware manufacturers lined up to support the framework. Siemens and Rockwell have not adopted CODESYS — they continue to develop and sell their proprietary environments. CODESYS is strongest among mid-tier hardware manufacturers and newer entrants. This limits its reach in the portion of the market dominated by the two largest PLC vendors.

Industrial context adds complexity — The stakes in industrial automation are higher than in hobby electronics. A misconfigured Arduino sketch crashes a hobby project. A misconfigured PLC program stops a production line or, in safety-critical applications, creates hazards. This higher-stakes environment means industrial customers are slower to adopt unfamiliar platforms, even when the technical case is strong.

---

Part 5: Who Is Using CODESYS and How

Despite the slower adoption curve, CODESYS has accumulated an impressive list of hardware partners and real-world deployments.

Beckhoff Automation — one of the largest and most respected industrial automation companies in Europe — built its entire TwinCAT platform on CODESYS. Beckhoff hardware running TwinCAT is effectively hardware running a customised CODESYS runtime. This is significant: Beckhoff is not a fringe player. It is a serious industrial automation company whose motion control and PC-based control products are specified in demanding applications worldwide.

Wago — a major manufacturer of terminal blocks and industrial controllers — uses CODESYS as the programming environment for its PFC (Programmable Fieldbus Controller) product line.

Bosch Rexroth uses CODESYS in several of its IndraMotion controller platforms.

Revolution Pi by KUNBUS — the RevPi runs CODESYS via the pibridge backplane at 200 Hz. This is a Raspberry Pi Compute Module in a DIN-rail industrial enclosure, programmed in IEC 61131-3 Structured Text or Ladder, for approximately €300.

Arduino Opta — Arduino's industrial micro PLC supports CODESYS-compatible IEC 61131-3 programming via the Arduino PLC IDE. An Arduino Opta running Structured Text is, from a programming perspective, the same experience as a Beckhoff controller running TwinCAT.

---

Part 6: Structured Text — The Language That Changes Everything

Of the five IEC 61131-3 languages, Structured Text (ST) deserves special attention because it is where CODESYS most powerfully demonstrates the Arduino parallel.

Ladder Diagram was designed for electricians. It is excellent for simple combinational logic — contacts, coils, timers, counters. For complex algorithms — PID control, state machines, mathematical transformations, communication protocols — Ladder becomes unwieldy. Tens of rungs to express what five lines of text would say clearly.

Structured Text looks like Pascal or modern high-level programming languages:

IF pressure > maxPressure THEN
    motorEnable := FALSE;
    alarmActive := TRUE;
ELSIF pressure < minPressure THEN
    motorEnable := TRUE;
END_IF;

Any software engineer can read this. Any mechanical engineer who has written MATLAB or Python can read this. The language is not intimidating. It is not arcane. It is expressive, maintainable, and readable by people who were not trained specifically as PLC programmers.

This matters for several reasons:

• Code maintainability — Structured Text code can be version-controlled with Git, reviewed by engineers who don't have PLC certifications, and maintained over long periods by teams with varying backgrounds.
• Algorithm complexity — PID controllers, force profiles, motion trajectories, communication state machines — all of these are significantly easier to implement and maintain in Structured Text than in Ladder.
• Attracting talent — recruiting a controls engineer who knows Python and is willing to learn Structured Text is considerably easier than recruiting one who has specifically trained on Siemens TIA Portal. The skill transfer path is much shorter.
• Portability — Structured Text written to the IEC 61131-3 standard is portable across any CODESYS-compatible platform. Moving from a RevPi to a Beckhoff controller, or from an Arduino Opta to a Wago PFC, requires hardware reconfiguration but not code rewriting.

---

Part 7: The Vendor Lock-In Problem and Why It Matters

The most important argument for CODESYS — and the most direct parallel to Arduino — is what it does to vendor lock-in.

When a company standardises on Siemens TIA Portal, several things happen over time:

• The engineering team builds expertise in TIA Portal specifically
• The machine code library accumulates in Siemens-specific formats
• Spare parts, support contracts, and training all run through Siemens channels
• Hardware decisions default to Siemens because switching platforms means retraining and code migration

None of this is malicious on Siemens' part. It is the natural consequence of a proprietary ecosystem. But from the end user's perspective, it means that hardware purchasing decisions are constrained by software investment, and competitive pressure on the hardware vendor is reduced.

CODESYS decouples the software investment from the hardware choice. If you have invested in CODESYS knowledge and a CODESYS code library, you can switch hardware manufacturers without losing either. A better-priced RevPi, a more capable Beckhoff module, a new entrant with attractive specifications — all are options without a software migration penalty.

This is not a theoretical benefit. For OEM machine builders, it means hardware cost reduction without retraining. For end users, it means maintenance and upgrade flexibility over a machine's 15–20 year lifetime. For the market as a whole, it means hardware manufacturers compete on price and capability rather than ecosystem lock-in.

---

Part 8: Where CODESYS Fits in the Future of Industrial Automation

Industrial automation is in the middle of a slow but real architectural shift. The traditional model — proprietary hardware, proprietary software, long refresh cycles, high switching costs — is being challenged from multiple directions simultaneously.

IIoT connectivity is pushing intelligence to the edge, where Linux-based IPCs are more capable than traditional PLCs. Software-defined automation — where the control logic is separated from the hardware and can be updated, migrated, or scaled independently — is gaining traction in the most technically progressive parts of the industry. Open standards — OPC-UA, MQTT, IEC 61131-3 — are replacing proprietary communication and programming interfaces.

CODESYS fits naturally into this future. It is already running on Linux-based IPCs (RevPi, Portenta X8). It is already interoperable with open IIoT standards. It is already vendor-neutral. It is already the most widely deployed independent PLC runtime in the world.

The question for engineers and companies making platform decisions today is not "will CODESYS survive?" but "how central will open, vendor-neutral platforms become to industrial automation over the next decade?" The direction of travel is clear. The speed is uncertain.

---

Conclusion

CODESYS did for PLC programming what Arduino did for embedded development: it separated the skill from the hardware credential, enabled new hardware entrants to compete with established players, and gave engineers a framework they could carry with them across different platforms.

It did not get the cultural moment. Industrial automation does not have hackathons and maker faires. The adoption curve has been slower because the stakes are higher and inertia is stronger.

But the effect is real. Over 500 hardware manufacturers. The foundation of Beckhoff's TwinCAT. The programming environment for Revolution Pi. The IEC 61131-3 runtime on Arduino Opta. A global community of controls engineers writing Structured Text that runs on any compatible hardware.

If you are a controls engineer who has been trained on one vendor's proprietary environment and never looked outside it — CODESYS is worth your time. If you are an OEM machine builder evaluating your control platform — the hardware flexibility that CODESYS enables is worth quantifying. If you are a company with a large installed base of proprietary PLC code wondering about your long-term options — the migration path to an open standard deserves a serious conversation.

The Arduino of PLCs has been here for a while. It just never made the front page. At Meekee, our servo press controller is built on CODESYS running on RevPi — because we believe control logic should be open, portable, and owned by the customer, not the vendor. Reach out if you'd like to discuss what an open automation architecture looks like for your application.