CODESYS soft-PLC vs hardware-target: deployment differences

For CODESYS CODESYS Development System V3.5.

CODESYS deploys to hardware targets (Wago, Beckhoff, Schneider M262) and to soft-PLC runtimes (Windows, Linux, Raspberry Pi). The differences that matter. This page is the working engineer's read — what the menu paths actually are in CODESYS Development System V3.5, what the keystrokes do, and the mistakes that bite once the program is on a real CPU. We program Soft-PLC + IEC 61131-3 hardware partners ourselves, daily; we are not a CODESYS sales channel.

What this is and when you need it

CODESYS deploys to hardware targets (Wago, Beckhoff, Schneider M262) and to soft-PLC runtimes (Windows, Linux, Raspberry Pi). The differences that matter. The walkthrough below is the same sequence we use when teaching this on the simulator. Every step names the exact menu path or keystroke; if a name has changed in your version of CODESYS Development System V3.5, it is called out. The simulator runs the same logic flow without the licence cost — ladder, FBD, and ST in a browser, with a virtual CPU you can download to.

Walkthrough

1. Understand the runtime split

CODESYS V3.5 is two things: an IDE and a runtime. The IDE runs on Windows. The runtime runs on the target. Hardware targets ship with the runtime preinstalled — Wago PFC200, Beckhoff CX, Schneider M262, Eaton XC. Soft-PLC runtimes are installed separately on Windows, Linux, or Raspberry Pi. Both runtime types speak the same protocol to the IDE — a project compiled for one target rarely runs unchanged on a different target.

2. Spec the soft-PLC option

CODESYS Control for Linux ARM ($30 to $300 depending on edition) runs on a Raspberry Pi 4 or 5 — useful for OEM development benches, low-cost data-collection nodes, or non-critical machines. CODESYS Control RTE for Windows runs on a real-time-extended Windows kernel and is used in test rigs. CODESYS Control for Linux SL is the deployment-grade Linux runtime for industrial PCs (Phoenix Contact, Beckhoff CX-L).

3. Configure the target via Device Tree

Device > Add Device > pick the runtime: 'CODESYS Control Win V3 x64' for soft-PLC on Windows, 'CODESYS Control for Raspberry Pi MC SL' for Pi, 'CODESYS Control RTE V3' for real-time Windows, or a hardware-vendor device like 'WAGO PFC200'. The device tree below the device shows the runtime's IO mapping, fieldbus drivers, and communication options.

// Device tree example (Raspberry Pi soft-PLC)
// CODESYS Control for Raspberry Pi MC SL
//   PLC Logic
//     Application
//       Library Manager
//       POUs
//   GPIO_Inputs (Raspberry Pi GPIO mapping)
//   Modbus_TCP_Master (TCP fieldbus to remote IO)
//   EtherCAT_Master (USB-EtherCAT or NIC)

4. Compile and download

Build > Generate Code (F11). Errors in the Build window. Online > Login (Alt+F8). The IDE asks for the target's IP and the CODESYS gateway; default is localhost on a soft-PLC, the device IP on hardware. The first login compiles for the target architecture (x86, ARM, x64) — incompatible POUs (vendor-specific FBs from one library) fail at compile, not at download. Online > Start (F5) runs the application.

5. Migrate between targets

A project compiled for soft-PLC Windows ports to Wago PFC200 with caveats: vendor-specific libraries (e.g., WagoTypesEthercatLin from Wago) only resolve on the Wago target; soft-PLC's Win-specific I/O drivers don't exist on hardware. Strategy: use vendor-neutral libraries where possible (CODESYS_StandardLib, Modbus, Util), isolate vendor-specific code into a separate POU group, and rewrite that group per target. The migration is cleaner than between vendor toolchains but not zero-effort.

Common mistakes

• Assuming a soft-PLC project ports unchanged to a Wago PFC200 — vendor-specific libraries break the build and only show up at the first target compile
• Running soft-PLC on Windows for production without the real-time extension — Windows scheduling jitter spikes to 50 ms under load and any time-critical logic misses
• Speccing CODESYS Control for Raspberry Pi for a process plant — the Pi's industrial reliability is below hardware PLCs and the customer expects 24/7 uptime
• Forgetting that soft-PLC licensing is per-runtime — moving the runtime to a different machine activates a new licence and the old machine stops running until reconciled

Each of these mistakes shows up in real projects every week. The simulator catches the first three at compile time; the fourth one only surfaces on hardware, which is why we recommend running the cert packs against a real CPU once you have completed the curriculum modules.

How this fits the broader curriculum

CODESYS soft-PLC vs hardware-target: deployment differences is one of the building blocks. The full CODESYS curriculum on the simulator covers: programming-language fundamentals (ladder, FBD, ST), tag and variable scope, HMI tag binding, comms setup (Profinet / EtherNet/IP / Modbus depending on the platform), and the brownfield troubleshooting pathway. Each is its own module with worked examples and a portfolio piece. The cert packs at the Pro tier align to the ISA CCST exam content outline. Reference: isa.org.

For the platform-pick decision — when CODESYS is the right call versus a different brand — see the brand hub. For region-specific context on where CODESYS dominates the SA install base, see the relevant city pages under /brands/codesys/training-in-* and the sector pages under /industries.

Where this sits in a working week

A technician who has finished this module typically spends the next three to four working days running the same logic flow on hardware. The simulator's value is the dry run — getting the keystrokes and the IDE conventions into muscle memory before you sit down with a live CPU. The first time you build this on hardware, expect the IO mapping and the addressing conventions to slow you down for a session or two; the simulator's project tree mirrors the same shape so the transition is short.

The full CODESYS curriculum runs roughly 60 to 100 hours of focused practice. That breaks into bit logic and timers in the first 20 hours, FBs and structured data in the next 20, comms and HMI in the next 20, and a portfolio piece in the last block. Pace yourself — three or four hours per session, four sessions a week, and you finish in eight weeks. Most of our learners report that the bottleneck is not understanding the IDE, it is building reflex around the conventions: where CODESYS expects you to put state, how it scopes variables, what naming patterns the OEMs in the sector use.

Vendor reference

CODESYS's own documentation is the canonical reference once you are working on real hardware: CODESYS Online Help. The simulator covers the basics; the vendor docs cover everything specific to a hardware revision, a firmware update, or a CPU-specific quirk. Bookmark both. The IEC 61131-3 standard that governs all the CODESYS programming languages is at iec.ch.

What we don't claim

This site is not SAQA-registered, not MerSETA-accredited, and not an NQF-registered qualification provider. Our completion certificates are course-level only — they describe what you covered, not an NQF Level X qualification. The CCST cert from ISA is the portable industry credential we recommend; we are not an ISA cert delivery partner either, but our cert packs are CCST-aligned. The walkthrough above is brand-specific because CODESYS's tooling has its own conventions; do not assume the same menu paths exist in another brand's IDE.

How to start

You can be running codesys soft-plc vs hardware-target: deployment differences in the simulator in 5 minutes. Free tier covers the basics, no card, no install. Once you are 20 minutes in you will know whether the platform fits how you learn. The full CODESYS curriculum is the Basic tier (USD 12 / month). The cert packs and portfolio export sit in the Pro tier (USD 29 / month). For institutional buyers — TVET colleges, private training providers, in-house engineering training departments — the bulk-licence option is the Teams tier, USD 199 per seat per year, minimum 5 seats. The training-centres page has the institutional pitch and the contact form.

Honest expectations on the local job market

Petrochem, mining, FMCG, automotive, and water-utility sectors all carry CODESYS install bases somewhere in their stack. Knowing the IDE conventions on this page does not get you a job by itself; it gets you past the first technical screen. The portfolio piece — a working program you built yourself, with a wiring track, a tag list, an HMI screen, and a short README explaining the design choices — is what lands the second interview. The simulator's portfolio export bundles all of that into a single folder you can hand a hiring engineer. Recruiters in this space skim the README first; if your design choices are coherent, they read the code.

Load-shedding has reshaped what gets built first in CODESYS programs across SA. Power-recovery patterns — controlled shutdown on UPS hold, state recovery from retentive memory, sequenced restart of motor groups — now belong in the same module as the basics. CODESYS soft-PLC vs hardware-target: deployment differences fits into that shape: every line of code you write needs to consider what state the controller is in when it powers up after a 2.5-hour cut, not just what state it is in when running. The simulator's restart-from-cut mode lets you exercise this without bricking real hardware.