CODESYS vs TwinCAT: Soft-PLC Architecture Compared (2026)
If you are selecting a soft-PLC runtime for a new machine or edge-control project in 2026, the CODESYS vs TwinCAT question will surface early and stay unresolved longer than you expect. Both platforms implement IEC 61131-3, both run on standard x86 hardware, and both claim sub-millisecond determinism. The architectural differences run deeper than the marketing materials let on, and choosing wrong means expensive re-engineering once the project is in motion.
A decade ago the debate had an easier answer: TwinCAT for Beckhoff shops, CODESYS for everyone else. By 2026 the landscape has shifted. CODESYS has meaningfully improved its EtherCAT stack and cloud management story. Beckhoff has introduced TwinCAT/BSD to address cost and security concerns on headless deployments. Both platforms now support OOP extensions, container integration, and OPC UA natively. The decision is genuinely harder, and it rewards a structured comparison rather than tribal loyalty to whichever platform the team last used.
This article is written for the automation engineer, system architect, or technical procurement lead who needs to make a defensible platform recommendation — not just pick the most familiar name. Every section maps to a real decision criterion with technical grounding.
What this covers: runtime architecture and real-time determinism, EtherCAT and fieldbus depth, IEC 61131-3 language support and extensions, development environment and version control, a weighted decision matrix, industry-vertical guidance, licensing and vendor-lock trade-offs, migration paths, and a practical recommendation checklist for 2026 procurement decisions.
Context: The Soft-PLC Landscape in 2026
Soft PLCs — programmable logic controller runtimes that execute on general-purpose CPUs instead of proprietary ASICs — have moved from niche to mainstream over the past decade. The shift accelerated when x86 multi-core processors became cheap enough to dedicate isolated cores purely to real-time control, eliminating the latency penalty that historically disqualified PC-based platforms from tight servo loops. Modern Intel Core and AMD Ryzen embedded processors with six or more cores make it practical to allocate two cores to the real-time runtime and still have ample headroom for the HMI, data logging, and network services running in parallel.
By 2026, two platforms dominate the serious automation conversation: CODESYS, developed by 3S-Smart Software Solutions, and TwinCAT 3, developed by Beckhoff Automation. A third tier of Linux-based open-source runtimes (OpenPLC, OSCAT) exists but remains outside the scope of most industrial OEM decisions where safety certification, fieldbus depth, and long-term support matter. Siemens S7 and Rockwell ControlLogix occupy their own category as hardware-bound proprietary PLCs, and this article deliberately sets them aside to focus on the soft-PLC decision.
The market split is not even. TwinCAT owns a commanding position in machine-builder and robotics applications where Beckhoff hardware is the natural BOM choice. CODESYS occupies the “runtime layer” role for dozens of OEM hardware vendors — Wago, Schneider Electric, Pilz, Bosch Rexroth, Lenze, and others — who license the runtime and ship it embedded in their own controllers. This vendor-OEM model is central to understanding why the two platforms are architecturally different at their cores. 3S does not sell hardware; Beckhoff does not license its runtime to competitors. That commercial asymmetry drives nearly every downstream technical and commercial trade-off covered in this article.
The soft-PLC wave is also accelerating due to Industry 4.0 and edge computing pressures. Machine builders increasingly need their controller to run OPC UA servers, REST endpoints, containerised analytics workloads, and MQTT brokers alongside the real-time scan cycle — tasks that are natural on a general-purpose CPU running Linux or Windows but awkward on a traditional hardware PLC. Both CODESYS and TwinCAT have responded with container support, Docker integration on TwinCAT/BSD, and CODESYS’s SoftContainer runtime, making the soft-PLC an increasingly attractive platform for converged IT/OT edge nodes.
Understanding both platforms also requires familiarity with OPC UA, the protocol increasingly used to surface PLC data to SCADA and cloud layers and with how SCADA historian architecture integrates with real-time control data in 2026.
CODESYS vs TwinCAT: The Core Comparison
Runtime Architecture and Determinism
TwinCAT 3’s real-time story is built around a Windows kernel extension called TcRTE (TwinCAT Real-Time Extension). TcRTE intercepts the Windows timer interrupt and reserves one or more CPU cores exclusively for TwinCAT tasks. Those isolated cores never run Windows threads, driver interrupts, or DPC callbacks. The result is deterministic task execution even on a Windows host, with cycle-to-cycle jitter in the range of 1-5 us on well-tuned Beckhoff IPC hardware running TwinCAT 3.1.
Beckhoff also ships TwinCAT/BSD, a FreeBSD-based operating system that replaces Windows entirely for headless runtime deployments. TwinCAT/BSD eliminates the Windows licensing cost and the overhead of a graphical OS, while keeping the same TcCOM object model and the same XAE (Visual Studio-based) development environment.
CODESYS takes a fundamentally different architectural stance. The runtime is a portable, OS-agnostic library that 3S licenses to hardware vendors. It binds to whatever scheduler the host OS provides — a PREEMPT_RT Linux kernel, a commercial RTOS like VxWorks or QNX, or even a bare-metal RTOS on an ARM SoC. Determinism therefore depends on the OS layer chosen by the hardware vendor, not on CODESYS itself.
On PREEMPT_RT Linux with a dedicated CPU core (via CPU affinity and cgroup isolation), a CODESYS task can achieve jitter in the 5-20 us range. On a hard RTOS substrate (QNX, VxWorks, or FreeRTOS with SMP extensions), jitter drops to 1-5 us — comparable to TwinCAT. The engineering implication is that CODESYS determinism is a function of platform selection, whereas TwinCAT’s determinism is largely a function of Beckhoff hardware configuration.
The diagram below shows the layered runtime stacks side by side.
Figure 1: CODESYS runtime sits on a portable HAL that adapts to many OS substrates. TwinCAT 3 uses TcRTE, a Windows kernel extension that isolates CPU cores for real-time tasks, or TwinCAT/BSD for headless deployments. The key distinction is that TwinCAT owns its OS integration layer while CODESYS delegates it to the hardware vendor.
Fieldbus, EtherCAT, and I/O Architecture
EtherCAT is where the gap between the two platforms is most visible in practice. Beckhoff invented EtherCAT and donates the specification to the EtherCAT Technology Group (ETG). TwinCAT’s EtherCAT master is therefore the reference implementation — it is deeply integrated into the TcRTE scheduler, and the EtherCAT cycle is synchronised directly to the control task clock. Distributed clocks across EtherCAT segments achieve synchronisation errors below 1 us across dozens of nodes.
The EtherCAT master in TwinCAT operates in a tight coupling with the real-time kernel. The master transmits one Ethernet frame per task cycle, processes all slave responses within the same cycle, and updates the process image atomically before the IEC 61131-3 program reads inputs. This architecture means there is no software queuing between the network card and the PLC program — the round-trip latency from physical input change to PLC variable update is bounded and deterministic. On a 1 ms cycle with a 100-node EtherCAT segment, the cable traversal time is roughly 26 us (at the EtherCAT specification’s 100 Mbit/s line rate), leaving ample margin for the PLC program to execute and write outputs before the next frame.
CODESYS supports EtherCAT through the CODESYS EtherCAT Master SL (SoftLayer) library. It is a conformant implementation and works well, but it executes as a software stack on top of the host OS network driver rather than being fused into the kernel extension the way Beckhoff’s master is. On PREEMPT_RT Linux hosts, this introduces an additional software layer whose jitter is measurable and must be budgeted for in tight motion applications. For applications with cycle times of 2 ms or longer and jitter budgets above 20 us, the CODESYS EtherCAT master performs adequately. For sub-millisecond servo loops requiring distributed-clock synchronisation below 5 us, TwinCAT’s integrated master is the safer choice.
For fieldbus protocols beyond EtherCAT, CODESYS has a structural advantage. Because the runtime ships embedded in controllers from dozens of vendors, it typically comes pre-integrated with Profibus, PROFINET, CANopen, Modbus TCP/RTU, EtherNet/IP, and CC-Link. Connecting a legacy Profibus network to a CODESYS-based controller from Wago or Schneider is straightforward. Connecting the same network to TwinCAT requires Beckhoff’s fieldbus interface cards or a gateway — which Beckhoff makes and sells, but which add cost and configuration complexity.
Both platforms support OPC UA as a northbound data interface, enabling integration with SCADA systems, MES, and cloud historians. TwinCAT’s TF6100 OPC UA server exposes the TwinCAT process image as an OPC UA address space and supports OPC UA DA, HA, and Alarms and Conditions. CODESYS’s built-in OPC UA server is available in the CODESYS runtime without a separate module purchase on most vendor implementations, though the address space configurability varies by vendor build. For large-scale OPC UA deployments with thousands of nodes, both platforms require careful configuration of subscription intervals, sampling rates, and publish intervals to avoid overwhelming the runtime’s non-real-time communication stack.
IEC 61131-3 Language Support and Extensions
Both platforms implement all five IEC 61131-3 languages: Structured Text (ST), Function Block Diagram (FBD), Sequential Function Chart (SFC), Ladder Diagram (LD), and Instruction List (IL). IL is formally deprecated in the 2013 edition of the standard, but both runtimes retain it for legacy compatibility.
TwinCAT 3 extends the standard with two significant additions. First, it integrates C and C++ modules as TcCOM (TwinCAT Component Object Model) objects alongside IEC 61131-3 POU blocks. An engineer can write a high-performance algorithm in C++, compile it to a TcCOM DLL, and call it from a Structured Text program with the same real-time guarantees as any other task. Second, TwinCAT integrates with MATLAB/Simulink via the TwinCAT Target for Simulink toolchain, enabling model-based design workflows where control algorithms are generated from Simulink block diagrams and run natively in the TcRTE.
CODESYS extends the standard through library management. The CODESYS Store distributes community and vendor libraries for motion, safety, networking, and vision tasks. The PLCopen motion control function block library is widely used in CODESYS and is the primary interface for axis control in multi-vendor environments. CODESYS also supports IEC 61131-3 object-oriented extensions (introduced in the third edition), including interfaces, methods, properties, and inheritance — a capability both platforms share and that TwinCAT equally supports.
For functional safety, TwinCAT offers TwinSAFE, a deeply integrated safety PLC layer that runs certified FSoE (Fail Safe over EtherCAT) communication. The TwinSAFE Logic component (EL6910) is a certified safety controller on the EtherCAT terminal rail, programmable from within TwinCAT XAE using standard safety FBs. This keeps the safety program in the same development environment as the standard PLC program, which significantly reduces the qualification effort under IEC 62061 and ISO 13849. CODESYS offers PLCopenSafety (CRC-encoded safety FB library) and depends on the hardware vendor to provide the safety certification layer — which vendors like Pilz (PSS 4000) and Bosch Rexroth (ctrlX SAFETY) do. The trade-off is that the CODESYS approach separates the certification burden onto the hardware vendor, which is appropriate when the system integrator does not want to manage a TUV certification process themselves.
One area where CODESYS has been closing the gap in 2025-2026 is the Automation Server cloud platform. 3S now offers a hosted service for remote PLC access, over-the-air updates, and fleet management of CODESYS-based devices. TwinCAT’s equivalent is Beckhoff’s TwinCAT Cloud Engineering and the ADS-over-MQTT infrastructure. Both represent the platforms’ responses to the demand for remote access and remote update capabilities in distributed machine fleets — a requirement that was aspirational five years ago but is now a standard procurement criterion for OEMs building networked machine portfolios.
Weighted Decision Matrix
The following table applies a 1-5 weight to each criterion and scores each platform 1-5. Multiply weight by score to compute a weighted score. Adjust weights to match your project’s priorities.
| Criterion | Weight | CODESYS Score | CODESYS Weighted | TwinCAT Score | TwinCAT Weighted |
|---|---|---|---|---|---|
| Real-time determinism (tuned RTOS/IPC) | 5 | 4 | 20 | 5 | 25 |
| EtherCAT master depth and sync | 4 | 3 | 12 | 5 | 20 |
| Multi-vendor hardware freedom | 5 | 5 | 25 | 2 | 10 |
| Legacy fieldbus coverage | 4 | 5 | 20 | 3 | 12 |
| IEC 61131-3 + OOP compliance | 3 | 5 | 15 | 5 | 15 |
| C/C++ and MATLAB integration | 3 | 2 | 6 | 5 | 15 |
| Motion control depth | 4 | 4 | 16 | 5 | 20 |
| Functional safety integration | 4 | 3 | 12 | 5 | 20 |
| Total runtime licensing cost | 3 | 3 | 9 | 3 | 9 |
| Ecosystem tooling and IDE quality | 3 | 4 | 12 | 4 | 12 |
| TOTAL | 147 | 158 |
Scores are based on published documentation, application notes, and typical project experience. A 1-point gap in the total is not decisive — adjust weights for your specific context. Multi-vendor hardware freedom is typically the tie-breaking factor.
The runtime stack diagram below illustrates why the EtherCAT and determinism rows diverge the way they do.
Figure 1: Side-by-side layer diagram of CODESYS and TwinCAT runtime stacks. TwinCAT’s TcRTE sits inside the OS kernel, giving it direct control over CPU core scheduling and EtherCAT frame timing. CODESYS’s portable HAL layer runs above the OS scheduler, which means determinism scales with the quality of the underlying OS — excellent on a hard RTOS, adequate on PREEMPT_RT Linux.
When to Choose Which
The matrix total is close, which accurately reflects reality: neither platform dominates universally. The decision turns on three questions answered early in the project.
Choose TwinCAT 3 when Beckhoff hardware is already in the bill of materials, when the application requires sub-100 us cycle times or highly synchronised multi-axis motion over EtherCAT distributed clocks, or when the team needs to integrate C++ algorithms or Simulink-generated control code directly in the runtime. Safety applications using FSoE benefit from TwinCAT’s TwinSAFE stack, which is certified under IEC 62061 and ISO 13849.
Choose CODESYS when the hardware vendor is already chosen and that vendor ships a CODESYS-based controller, when the project must run on multiple hardware platforms (embedded Linux panels, PLCs from different manufacturers, custom ARM SoCs), or when the organisation’s procurement rules prohibit single-vendor lock-in for the control layer. CODESYS is also the natural choice when migrating existing programs from another CODESYS-based vendor platform, since the IEC 61131-3 codebase transfers with minimal re-work.
The decision tree below formalises these conditions.
Figure 2: A structured decision tree for the CODESYS vs TwinCAT choice. Start with hardware BOM commitments, then evaluate cycle-time requirements, multi-vendor needs, EtherCAT depth, and integrated safety requirements. Projects that branch left at “hardware vendor already chosen” almost always land on CODESYS. Projects that branch right at “sub-100 us cycle or distributed-clock sync” almost always land on TwinCAT.
For context on how this decision fits within the broader PLC and SCADA selection landscape, see our comparison of PLC and SCADA architectures.
Industry-Vertical Guidance
Packaging and converting machinery: TwinCAT dominates in high-speed camming and flying-shear applications where electronic line shaft synchronisation across 8-32 axes requires distributed-clock accuracy at sub-microsecond synchronisation. The tight integration between TwinCAT NC Task and EtherCAT distributed clocks makes this a natural fit. CODESYS with PLCopen motion on a hard-RTOS Bosch Rexroth ctrlX CORE is a credible alternative for packaging lines where the OEM has an existing Rexroth drive relationship.
Water and wastewater, building automation, and utilities: CODESYS is the dominant choice. Wago PFC controllers, Schneider Electric Modicon M262, and Phoenix Contact PLCnext all run CODESYS, and the fieldbus diversity (Modbus, PROFINET, BACnet) is better matched to the heterogeneous I/O landscape in process plants. Cycle times in these applications are typically 10-100 ms, well within CODESYS on PREEMPT_RT Linux. TwinCAT is rarely specified in this vertical outside of Beckhoff-loyal system integrators.
Robotics and collaborative robot cells: Both platforms are active here. Beckhoff’s TwinCAT Kinematic Transformation (TF5110) library supports delta, SCARA, and 6-DOF kinematics natively. CODESYS implementations typically rely on the robot manufacturer’s proprietary motion stack running on a separate controller, with CODESYS handling cell coordination. For custom robot builders, TwinCAT’s C++ TcCOM integration for custom kinematics algorithms is a significant advantage.
Semiconductor and electronics manufacturing: Ultra-low jitter requirements (often below 5 us at 250 us cycle times) favour TwinCAT on Beckhoff IPC hardware. This vertical also tends to use custom C++ control libraries for wafer handling and precision positioning, which maps directly to TwinCAT’s TcCOM architecture.
Custom OEM hardware and IoT gateway controllers: When the machine builder is developing a proprietary hardware platform (custom ARM SoC, industrial PC with a custom carrier board), CODESYS’s OEM runtime license model is the only practical choice. Building TwinCAT into non-Beckhoff hardware is not an option Beckhoff supports commercially. The CODESYS Runtime Toolkit enables full IEC 61131-3 execution on custom Linux-based hardware, which is increasingly the architecture chosen for converged edge controllers that combine PLC logic with containerised analytics and cloud connectivity.
Trade-offs and Gotchas
Licensing: More Complex Than It Appears
TwinCAT 3’s runtime license is tied to the Beckhoff hardware — specifically to a dongle or software license bound to the IPC’s CPU or CX controller. The base runtime is free with Beckhoff hardware. Adding TwinCAT modules like TF5000 (NC PTP motion), TF6100 (OPC UA server), or TF5250 (CNC) each carries a separate license fee. A fully-featured TwinCAT installation with motion, OPC UA, and safety can cost several hundred euros in module licenses per machine, in addition to hardware costs.
CODESYS licensing depends entirely on the hardware vendor’s model. Some vendors (Wago, for instance) include the CODESYS runtime in the hardware price with no separate runtime license. Others charge a runtime license per device. The CODESYS Development System (IDE) itself is free to download and use. If you are building a custom controller with the CODESYS runtime embedded, 3S charges a per-unit OEM runtime license — contact 3S directly for volume pricing, as this is not publicly published.
The practical implication: CODESYS total cost is harder to forecast in a custom hardware scenario. TwinCAT total cost is transparent as long as Beckhoff hardware is assumed.
Vendor Lock-In
TwinCAT creates deep hardware lock-in with Beckhoff. Migrating a TwinCAT application to a different runtime means rewriting C++ TcCOM modules, re-certifying safety functions, and re-configuring the EtherCAT topology. The IEC 61131-3 Structured Text code itself is portable, but the integration layer is not.
CODESYS avoids this at the runtime level — a CODESYS ST program can move between Wago, Schneider, and Pilz hardware with manageable effort. The gotcha is that vendor-specific library additions (Wago’s WagoLibFeldbusModule, Bosch Rexroth’s ctrlX-specific FBs) create a new layer of lock-in at the application level. Discipline in using only PLCopen-standard FBs mitigates this, but most real projects accumulate vendor-specific dependencies over time.
Hardware Coupling and Availability
Beckhoff IPC hardware is generally available and well-supported globally, but it is a single vendor. Supply chain disruptions or Beckhoff pricing changes directly affect TwinCAT projects. CODESYS-based hardware comes from a much wider supplier base, which provides redundancy in sourcing and competitive pressure on pricing.
On the other hand, Beckhoff’s hardware-software integration means fewer integration surprises. A Beckhoff CX7000 running TwinCAT is a known-good configuration. A CODESYS runtime on a custom ARM board with PREEMPT_RT Linux requires careful configuration of CPU affinity, IRQ routing, and network driver priority to achieve the advertised real-time performance.
The hardware coupling question extends to the I/O terminal ecosystem. Beckhoff’s EtherCAT terminal range (the EL and EP series) covers digital I/O, analog I/O, encoder interfaces, motor outputs, condition monitoring inputs, and safety terminals in a unified form factor with unified engineering in TwinCAT System Manager. This breadth means a TwinCAT-based machine can source nearly all I/O from a single vendor with guaranteed compatibility. CODESYS systems typically use EtherCAT I/O from the same hardware vendor’s product line, or third-party EtherCAT slaves from companies like Weidmuller or Phoenix Contact — all conformant to the ETG specification and fully interoperable with the CODESYS EtherCAT master.
The long-term support question is worth examining explicitly. Beckhoff has committed to TwinCAT 3.1 as the active release branch and publishes a clear product lifecycle policy in InfoSys. CODESYS 3.5 is the active branch, with 3S committing to backward compatibility for project files across minor versions. Both vendors have strong track records for industrial longevity — machine lifecycles of 15-25 years are common in the sectors both platforms serve, and neither vendor has shown signs of abandoning active platform support.
Migration Paths Between Platforms
Migration from TwinCAT to CODESYS or vice versa is occasionally necessary — after acquisitions, hardware supply disruptions, or when OEM customers mandate a specific platform. Understanding the migration scope upfront prevents surprises.
Moving from TwinCAT to CODESYS: The IEC 61131-3 Structured Text, FBD, and SFC program bodies copy across with minimal changes. The hard work lies in replacing TwinCAT-specific libraries. Every TcSystem, TcUtilities, and TcMath function block call needs a CODESYS equivalent — most have direct counterparts but require manual substitution. EtherCAT I/O configuration must be rebuilt in the CODESYS EtherCAT Configurator. TcCOM C++ modules have no equivalent in CODESYS and must be reimplemented as external libraries or restructured into IEC 61131-3. TwinSAFE safety programs require complete re-engineering against the target hardware vendor’s safety certification.
Moving from CODESYS to TwinCAT: Program body migration is similarly straightforward for standard code. PLCopen motion FBs map to TwinCAT’s MC2 motion library with minor signature differences. The main complication is CODESYS OOP code — interfaces and method calls are supported in TwinCAT, but the runtime OOP model has subtle differences in inheritance resolution that can cause unexpected behaviour if not audited. Fieldbus configurations built on PROFINET or CANopen must be re-mapped to Beckhoff fieldbus cards, which adds both hardware cost and commissioning time.
A practical mitigation strategy for either direction: write new code exclusively to PLCopen and IEC 61131-3 standards, encapsulate all vendor-specific function blocks behind wrapper FBs with standard interfaces, and maintain the EtherCAT I/O configuration as a separately-versioned XML document. Projects that follow this discipline reduce migration effort substantially.
Control Task Scheduling and Jitter
The scheduling diagrams below illustrate how each platform handles multi-task execution and where jitter originates.
Figure 3: TwinCAT (right) isolates real-time tasks on dedicated CPU cores via TcRTE, achieving 1-5 us jitter on tuned Beckhoff IPC hardware. CODESYS (left) binds to the host OS priority thread; jitter on PREEMPT_RT Linux is typically 5-20 us, dropping to 1-5 us on a hard RTOS substrate. The shaded regions show where non-deterministic OS events can intrude on each platform’s task execution window.
A practical note from the Beckhoff InfoSys documentation on TwinCAT real-time: isolating CPU cores requires setting the correct CPU mask in TwinCAT System Manager and disabling C-state transitions in the BIOS. Missing either step causes jitter spikes that are difficult to diagnose.
For CODESYS on PREEMPT_RT Linux, the CODESYS Runtime Toolkit documentation documents the SysCpuMultiCore configuration for CPU pinning and the SysTarget watchdog settings. Applying these correctly is a prerequisite for achieving rated determinism.
Practical Recommendations
Use this checklist when making the final platform decision on a 2026 project.
Before finalising hardware:
- Confirm whether EtherCAT distributed clocks are required for multi-axis synchronisation. If yes, TwinCAT’s native EtherCAT master is the lower-risk choice.
- List all fieldbus protocols already present in the plant. If Profibus, PROFINET, or CANopen segments exist, audit whether the chosen hardware vendor’s CODESYS build includes tested drivers for those protocols.
- Check whether functional safety (SIL 2 or PLe) is required on the same controller. TwinCAT TwinSAFE is simpler to certify on Beckhoff hardware than assembling a certified CODESYS safety stack from a third-party vendor.
At the software architecture stage:
- Determine whether C++ or MATLAB-generated code will run in the real-time context. TwinCAT TcCOM objects handle this natively. CODESYS lacks an equivalent first-class C++ integration path at the runtime level.
- Define the OPC UA surface area early. Both platforms support OPC UA server functionality, but TwinCAT’s TF6100 module and CODESYS’s built-in OPC UA server have different configuration models and address space limitations. Test with your expected node count.
- Confirm PLCopen motion profiles are sufficient, or whether vendor-specific motion FBs will be required. Vendor FBs create future migration cost.
At the procurement stage:
- Get itemised TwinCAT module license quotes per machine before committing to the architecture. TF5000 (motion) + TF6100 (OPC UA) + TF5810 (condition monitoring) adds up quickly.
- For CODESYS OEM builds, request the runtime SLA and firmware update commitment from the hardware vendor. 3S releases runtime updates; your vendor controls when those updates reach your hardware.
- Evaluate TwinCAT/BSD as an alternative to Windows-based TwinCAT for cost-sensitive headless deployments. BSD eliminates the Windows license and reduces the attack surface for OT security.
- Ask both vendors about their remote access and OTA update story for deployed machine fleets. TwinCAT’s ADS-over-MQTT and Beckhoff’s cloud engineering tooling versus CODESYS Automation Server each have different pricing and scalability models.
Cybersecurity considerations for 2026:
Soft-PLCs running on networked industrial PCs have a larger attack surface than traditional hardware PLCs with proprietary communication stacks. Both platforms now publish security hardening guides. For TwinCAT deployments, Beckhoff’s InfoSys includes a dedicated security section covering user authentication, ADS firewall configuration, and network isolation recommendations. For CODESYS deployments, 3S published a Security White Paper addressing encrypted communication via CODESYS Security Agent and role-based access control in the runtime. In either case, follow the IEC 62443-4-2 component hardening requirements for the runtime and ensure that the EtherCAT master network segment is physically or VLAN-isolated from the IT network.
Proof-of-concept before full commitment:
The fastest way to de-risk the CODESYS vs TwinCAT decision is to build a two-week proof of concept using the actual hardware and a representative motion or I/O task. TwinCAT 3 offers a free trial license valid for 7 days with full functionality — sufficient for benchmarking jitter, EtherCAT topology commissioning, and a sample motion sequence. CODESYS’s Development System is entirely free; runtime licenses on evaluation hardware from most vendors are available as demo units. Running both PoCs in parallel on equivalent hardware gives you measured jitter numbers and integration complexity data that no specification sheet can substitute for.
The deployment topology below shows what the full stack looks like from engineering station through the runtime to I/O and the cloud historian layer.
Figure 4: A typical soft-PLC deployment. The engineering station (TwinCAT XAE or CODESYS IDE) downloads program and configuration to the runtime over Ethernet. The runtime drives EtherCAT I/O at 1 ms cycle time and exposes process data to SCADA or cloud via OPC UA. The distinction between the two platforms at this layer is largely invisible — the OPC UA address space looks identical to the historian regardless of which runtime produced it.
What Changes in 2026 and Beyond
Three trends are actively reshaping the CODESYS vs TwinCAT comparison and deserve attention in any 2026 evaluation.
Containerisation and the IT/OT convergence layer. Both platforms are responding to the demand for co-locating PLC logic with containerised workloads on the same industrial PC. Beckhoff’s TwinCAT/BSD supports Docker on the non-real-time partition, enabling analytics containers, MQTT brokers, or Node-RED flows to run alongside TwinCAT while the RT partition maintains its guarantees. CODESYS’s SoftContainer runtime similarly targets Linux-based edge controllers where the PLC runtime shares a host with containerised IT services. Engineers should evaluate how each platform isolates the real-time partition from the container runtime in terms of CPU and memory pressure. A runaway container should never jeopardise the PLC scan cycle, and each platform approaches that isolation differently.
AI-assisted programming and code generation. Large language models are beginning to appear as coding assistants for IEC 61131-3. Both Beckhoff and 3S have indicated roadmap interest in AI-assisted development tooling within the respective IDEs. At present, LLM-class models can generate usable Structured Text fragments when given clear specifications, but they hallucinate library function signatures and produce unsafe code for safety-critical sections. Engineers using AI coding tools with either platform must validate every generated function block against the platform’s published library documentation before deployment. This is not yet a platform differentiator but will become one as first-party integrations mature.
Open-source and community runtime alternatives gaining ground. The PLCnext Technology platform from Phoenix Contact combines a CODESYS-compatible runtime with an open Linux environment, contributing to an ecosystem of shared libraries and community-authored extensions. Beckhoff’s TwinCAT/BSD, by contrast, maintains a closed development model. For organisations with open-source policies or community engagement strategies, this distinction matters. The CODESYS ecosystem’s breadth — hundreds of hardware vendors, thousands of system integrators, and an active store of shared libraries — represents a form of resilience that a single-vendor platform cannot replicate, even if the single-vendor platform offers tighter vertical integration.
Security certification requirements tightening. IEC 62443-4-2 compliance for PLC components is increasingly requested in tender documents for critical infrastructure, energy, and defence-adjacent applications. Both 3S and Beckhoff are actively pursuing relevant certifications. Evaluate your sector’s specific requirements and confirm with each vendor what certifications are currently held for the runtime version you intend to deploy — not a future roadmap version.
FAQ
What is the difference between CODESYS and TwinCAT at the architectural level?
CODESYS is a portable runtime library developed by 3S-Smart Software Solutions that hardware vendors embed in their own controllers. TwinCAT 3 is Beckhoff’s proprietary real-time framework, tightly integrated with Beckhoff IPC hardware via the TcRTE kernel extension or TwinCAT/BSD. CODESYS abstracts over many OS substrates; TwinCAT achieves determinism by owning the OS integration layer entirely. The commercial consequence is that CODESYS runs on dozens of vendors’ hardware while TwinCAT runs only on Beckhoff’s.
Is TwinCAT faster than CODESYS?
On Beckhoff hardware with TcRTE and isolated CPU cores, TwinCAT achieves cycle-to-cycle jitter of 1-5 us, which is among the best available for a soft-PLC runtime. CODESYS on a well-configured PREEMPT_RT Linux host typically achieves 5-20 us jitter, narrowing to 1-5 us on a hard RTOS. “Faster” is the wrong frame — the question is whether the jitter budget meets the application requirement. For a 10 ms process control loop, both platforms are identical in practice. For a 250 us precision servo loop, the difference is real and measurable.
Can CODESYS run on Beckhoff hardware?
CODESYS does not officially run on Beckhoff IPC hardware. Beckhoff’s controllers ship with TwinCAT, and Beckhoff does not license CODESYS for its platforms. Some engineers run CODESYS on commodity x86 hardware sourced independently, but this bypasses the Beckhoff supply chain entirely. If you want a CODESYS runtime on IPC-class x86 hardware, the practical path is commodity industrial PCs from vendors like Kontron, Advantech, or Nexcom running the hardware vendor’s CODESYS build.
Are CODESYS and TwinCAT programs portable between each other?
IEC 61131-3 Structured Text, FBD, and SFC code written to the pure standard will transfer between the two platforms with moderate effort. The main friction points are TwinCAT-specific library references (TcSystem, TcMath, TwinSAFE FBs), vendor-specific CODESYS libraries, and hardware configuration (I/O mapping, EtherCAT topology). Expect 20-40% re-work on a real project migration, depending on how many vendor-specific elements were used. Projects that follow PLCopen-only coding standards from day one cut that estimate significantly.
Does CODESYS support EtherCAT?
Yes. CODESYS provides the CODESYS EtherCAT Master SL library, which is an ETG-conformant EtherCAT master implementation. It supports distributed clocks, hot-connect segments, and cable redundancy. Performance on PREEMPT_RT Linux is very good for most applications — cycle times of 2 ms and above with distributed clock synchronisation errors well under 100 us. For the tightest multi-axis synchronisation requirements (sub-10 us distributed clock error at 500 us cycles), TwinCAT’s kernel-integrated master has a measurable and reproducible advantage.
What is TwinCAT/BSD and when should I use it?
TwinCAT/BSD is a FreeBSD-based operating system that Beckhoff ships as an alternative to Windows for headless TwinCAT runtime deployments. It eliminates the Windows license cost, reduces the software attack surface, and simplifies deployment on Beckhoff CX series embedded PCs. Use it for new headless controller deployments where you do not need a local HMI running on the same box. The full TwinCAT XAE development environment still runs on a separate Windows engineering station; TwinCAT/BSD is purely a runtime OS. Beckhoff introduced TwinCAT/BSD partly in response to OT security guidance recommending minimal OS footprints on production controllers.
Further Reading
- Beckhoff InfoSys — TwinCAT 3 Overview and Real-Time Documentation
- CODESYS Runtime Toolkit — System Configuration and Determinism
- EtherCAT Technology Group — Technology Overview
- PLCopen Motion Control Function Blocks Specification
- OPC UA Protocol: Complete Technical Guide
- PLC vs SCADA: Architecture Compared
- SCADA Historian Architecture 2026
Riju writes about industrial automation architecture, IIoT, and digital twin platforms at iotdigitaltwinplm.com.
