If you are building a custom robotic cell, a test rig, or an automated packing machine, the hardware bill of materials is usually the easy part. You pick some linear actuators, wire up optical sensors, mount servo drives, and lay out an electrical backplate. The friction starts when you have to decide what executes the logic.
If you come from a mechatronics, software, or mechanical background, your instinct is to treat the industrial controller like any other computer. You want an IDE you can install on your laptop without calling a sales rep, standard networking over basic Ethernet cables, and code you can check into a Git repository.
Then you look at the pricing for Rockwell Automation's Studio 5000 or Siemens TIA Portal, discover annual subscription fees running into thousands of dollars per seat, and realize your controller choice dictates everything from your fieldbus architecture to your bill of materials margins.
This is where Codesys and software-based programmable logic controllers enter the conversation. But choosing a hardware-agnostic runtime over the industry giants is not just an anti-vendor stance. It changes how you source parts, how you debug fieldbuses, and whether a customer's maintenance crew will accept your machine on their plant floor.
The Software Licensing Barrier
To understand why independent machine builders push for Codesys, look at how software licensing works in the traditional automation world.
If you choose Rockwell Automation (Allen-Bradley), you generally program the CompactLogix or ControlLogix families using Studio 5000 Logix Designer. A perpetual or subscription license for Studio 5000 can cost between $1,500 and $10,000 depending on the edition (Standard, Full, or Professional) and whether you need support for motion control, functional safety, and Structured Text. If you have two engineers modifying code or troubleshooting panels in the field, both need paid seats managed through Rockwell's FactoryTalk Activation Manager.
Siemens operates similarly with TIA Portal (Totally Integrated Automation). While Step 7 Basic covers the entry-level S7-1200 micro-PLCs at a relatively accessible price, stepping up to S7-1500 controllers or integrated motion requires Step 7 Professional, accompanied by floating USB dongle licenses or complex license servers. Every major version upgrade (V17, V18, V19, V20) often requires a paid upgrade package or an active software update service contract.
Codesys takes the opposite path. The core Codesys development environment (currently V3.5) is free to download and install. Anyone on your team can open a project, write logic, configure fieldbus networks, and test code using the built-in soft simulation without paying a cent or activating a license key.
Codesys makes its money through runtime licenses and modular add-ons. Instead of charging the engineer to write the code, the cost is tied to the target hardware. When you buy a dedicated Codesys-based PLC from vendors like WAGO, Turck, Festo, or Eaton, the vendor has already baked the Codesys runtime license into the hardware price. If you prefer to run a SoftPLC on a generic x86 industrial PC or an ARM board running Linux (like a Raspberry Pi CM4 carrier), you buy a runtime license directly from the Codesys Store for a one-time fee ranging from roughly $60 to $500, depending on performance tiers and motion axes.
For an OEM building tens or hundreds of machines, or an engineering firm prototyping bespoke test fixtures, the Codesys model removes massive upfront engineering overhead.
Hardware Freedom vs the Supply Chain
When you commit to Rockwell or Siemens, your hardware choices are narrow. A Rockwell Logix program runs on Rockwell hardware. A Siemens TIA Portal project runs on Siemens hardware. If a CompactLogix 5069-L306ER controller has a 40-week lead time, your shipment dates slip unless you redesign the control architecture or pay double on the grey market.
With Codesys, the runtime is decoupled from the silicon. The same development environment targets dozens of independent hardware manufacturers:
- Modular fieldbus controllers (such as the WAGO PFC200 or 750 series).
- Rugged IP67 block controllers designed for mobile hydraulics and harsh environments (Turck, ifm).
- Motion-centric slice systems (Festo, Schneider Electric's PacDrive and Modicon lines running EcoStruxure Machine Expert, which is a customized Codesys shell).
- Industrial PCs from Advantech, Beckhoff (via TwinCAT, which shares architectural roots with Codesys), or generic DIN-rail box PCs running real-time Linux kernels with
PREEMPT_RT.
If a specific I/O module goes out of stock, you can switch vendors without throwing away your control algorithms. You can run your primary controller on an x86 industrial PC from one vendor, mount remote slice I/O from a second, and drive servo motors from a third.
However, hardware independence has a hidden cost: hardware integration friction. When you use Rockwell, a 1769 or 5069 I/O card connects to the controller seamlessly. The configuration parameters, fault diagnostics, and tag structures generate automatically. When you assemble a multi-vendor Codesys system, you are responsible for importing device description files (XML, GSDML, or EDS), mapping raw memory words to variable structs, and verifying that the bus cycle timing does not introduce jitter.
Fieldbus Protocols: EtherCAT, Profinet, and Ethernet/IP
Your control runtime dictates how your controller communicates with drives, remote I/O, pneumatic manifolds, and vision sensors. The three dominant industrial Ethernet protocols behave very differently across these platforms.
EtherCAT: The Codesys Sweet Spot
EtherCAT is master-slave (or main-subordinate) based and relies on processing data on the fly. The master sends an Ethernet telegram through all nodes in a ring or line topology, and each node reads its output data and writes its input data within nanoseconds as the frame passes through.
For builders using Codesys or Beckhoff TwinCAT, EtherCAT is usually the best choice. It requires no specialized master hardware. Any standard Intel or Realtek Ethernet NIC on an industrial PC can serve as an EtherCAT master. You do not need expensive managed switches; the physical cables simply daisy-chain from drive to drive. EtherCAT I/O slices from brands like Beckhoff, WAGO, or generic Asian automation suppliers are significantly cheaper per point than proprietary Rockwell or Siemens racks, while delivering sub-millisecond deterministic cycle times.
Ethernet/IP: The Rockwell Domain
Ethernet/IP uses standard TCP/IP and UDP encapsulation via the Common Industrial Protocol (CIP). It relies heavily on standard network infrastructure, but achieving high performance and deterministic motion requires CIP Motion support and managed switches with Precision Time Protocol (IEEE 1588).
Rockwell natively excels here. Adding a PowerFlex drive or a Point I/O rack over Ethernet/IP in Studio 5000 is straightforward. Codesys can act as an Ethernet/IP scanner (master) or adapter (slave), but configuring third-party CIP connections often requires tedious manual mapping of Assembly Instances and input/output byte arrays using device EDS (Electronic Data Sheet) files.
Profinet: The Siemens Standard
Profinet, specifically Profinet IRT (Isochronous Real-Time), is Siemens' native protocol. It offers exceptional performance and deterministic motion synchronization, but it traditionally relies on specialized ASIC hardware (like Siemens ERTEC chips) in the master and slave devices.
While Codesys includes a software Profinet controller stack that runs on standard NICs, setting up Profinet GSDML files, device names, and IP assignment rules in Codesys can be finicky compared to the smooth drag-and-drop hardware catalog inside Siemens TIA Portal.
| Feature / Metric | Rockwell (Studio 5000) | Siemens (TIA Portal) | Codesys V3.5 / Open SoftPLC |
|---|---|---|---|
| IDE Cost | High ($1,500 to $10,000+ per seat) | Moderate to High ($500 to $5,000+) | Free IDE download |
| Runtime Licensing | Bundled in expensive hardware | Bundled in proprietary hardware | Per-device license or included by OEM |
| Hardware Lock-in | Complete (Rockwell hardware only) | Complete (Siemens hardware only) | Very low (Multi-vendor and generic IPCs) |
| Native Motion Fieldbus | Ethernet/IP (CIP Sync/Motion) | Profinet (RT/IRT) | EtherCAT, CANopen, Profinet RT |
| Version Control Support | Clunky (Binary ACD files, expensive tools) | Moderate (Openness API, Project Server) | Clean (Plain text/XML exports, native Git plugin) |
| US Factory Acceptance | Near universal standard | Common in automotive / European transplants | Low to moderate (growing in machinery OEMs) |
The Portability Myth in IEC 61131-3
Sales brochures often claim that because Rockwell, Siemens, and Codesys all comply with the IEC 61131-3 standard, your automation logic is fully portable between them. This is largely a myth.
IEC 61131-3 defines five core programming languages:
- Ladder Diagram (LD)
- Structured Text (ST)
- Function Block Diagram (FBD)
- Sequential Function Chart (SFC)
- Instruction List (IL, deprecated in modern revisions)
While the baseline syntax of Structured Text looks similar across platforms (using IF, CASE, FOR, and basic assignments), the runtime implementations, memory models, and system libraries vary drastically.
For example, standard timer blocks like TON or TOF in Codesys take time literals defined as T#500ms or TIME#2s. Rockwell Studio 5000 uses a dedicated TIMER data type with .PRE, .ACC, and .DN integer/boolean members measured strictly in milliseconds. Passing standard timer structures between the two requires rewriting your logic blocks.
Variable addressing also splits the field. Rockwell uses a flat, tag-based memory structure without fixed memory addresses. Siemens S7-1500 uses symbolic addressing alongside legacy DB (Data Block) offsets. Codesys uses a structured hierarchy combining global variable lists (GVLs), local program scopes, and direct pointer or reference memory management.
If you write pure mathematical algorithms, state machines, or data parsing routines in Structured Text, porting the code from Codesys to Siemens or Rockwell takes relatively little effort. But anything involving hardware interaction, motion axes (PLCopen Part 1 vs Rockwell motion instructions), communications sockets, or alarm handling must be re-engineered for the specific runtime.
At LabCD, when we work on automated control panel design and logic synthesis, handling these platform-specific dialect differences is one of the hardest problems to solve cleanly. An abstraction layer only works if it respects the physical realities of the controller executing the scan cycle.
The 2:00 AM Maintenance Problem
Before you choose Codesys to save $5,000 on software licenses and 30% on your I/O bills, you must evaluate who will maintain your machine after delivery.
This is where many mechatronics startups and bespoke automation builders run into a wall. If your machine is sold to a major manufacturing facility, an automotive plant, or a regional utility in North America or the Middle East, the plant's internal specifications almost certainly mandate Rockwell or Siemens.
Plant maintenance technicians know how to plug a laptop into a Rockwell panel, open Studio 5000, find a rung of Ladder Diagram, and see which physical interlock is holding open a safety circuit. They have spare 1756 or 5069 I/O modules sitting in their maintenance crib.
If you hand them a panel containing an industrial PC running a Codesys runtime over EtherCAT, written entirely in object-oriented Structured Text with custom pointer interfaces, they will not troubleshoot it. If a sensor fails or an axis faults at 2:00 AM, the machine simply sits idle until your service team answers the phone.
Even if Codesys is technically superior for your dynamic path planning or multi-axis coordinated motion, customer specifications often override technical preference. If the plant standard is Siemens S7-1500 with TIA Portal V18, fighting that requirement is usually a losing battle.
When Codesys Is the Correct Engineering Choice
Despite the plant-floor friction, there are three scenarios where picking Codesys (or a Codesys-derived platform like TwinCAT) is the right engineering decision:
1. You Build Standalone Machines at Volume (OEM Machinery)
If you manufacture serial machinery (such as packaging lines, lab automation units, CNC cutters, or agricultural equipment) that operates independently of a centralized factory supervisory system, you control the hardware spec. Paying Rockwell thousands of dollars per machine for proprietary hardware cuts straight into your gross margins. Standardizing on an industrial PC with a Codesys runtime and low-cost EtherCAT slice I/O can save hundreds of thousands of dollars a year across a production run.
2. High-Density Motion and Complex Kinematics
If your project requires controlling 16 synchronized servo axes, robotic delta kinematics, or custom motion profiles, traditional PLC ladder programming becomes unmanageable. Codesys SoftMotion provides built-in PLCopen motion blocks, CNC interpolators, and kinematic transformations directly inside the core IDE. Doing the same work on Rockwell often requires stepping up to high-end ControlLogix processors and costly motion modules.
3. Modern Software Engineering Workflows
Because Codesys projects can be saved in open formats or managed via official Git integration plugins, it fits neatly into automated testing, continuous integration, and modular library architectures. If your team treats control code like modern application software, with unit tests and automated builds, the legacy single-binary formats of traditional PLCs will only slow you down.
A Pragmatic Decision Framework
When evaluating controller platforms for your next build, avoid ideological decisions. Use this checklist to select the runtime stack:
- Check the customer specification first. If the end client has an approved vendor list (AVL) mandating Rockwell, Siemens, or Schneider Electric, use what they specify and price the software licenses and hardware premiums directly into your quote.
- Evaluate the internal development team. If your engineers are primarily mechanical or mechatronics generalists who write C++, Python, or Structured Text, they will adapt to Codesys or Beckhoff TwinCAT in days. If your team consists of seasoned panel builders and industrial electricians, forcing them off Rockwell or Siemens ladder logic will cause massive project delays.
- Assess the physical I/O and motion count. For systems with simple digital sensors and two or three VFDs, an entry-level Siemens S7-1200 or Rockwell Micro800 / CompactLogix 5370 will work reliably and maintain wide acceptance. For systems requiring dense I/O, vision processing, high-speed EtherCAT communications, or custom coordinated motion, build on an industrial PC running Codesys.
- Plan your diagnostics strategy. If you build with Codesys, build an intuitive, comprehensive web visualization (WebVisu) directly into the controller. If the plant technician can diagnose blown fuses, broken photoeyes, and failed limits directly from an HMI screen without ever opening the Codesys IDE, the lack of local Rockwell knowledge ceases to be an issue.
Take a close look at your bill of materials for upcoming projects. If software seats and proprietary slice I/O are inflating your build costs by more than 20%, download the Codesys development environment, buy a $100 evaluation runtime or an inexpensive edge controller, and set up a small EtherCAT test bench on your desk. Understanding the differences before you write your next controls proposal will save you weeks of redesign in the panel shop.
