Is CODESYS Any Good Inside a Rockwell or Siemens Plant?

Is CODESYS any good? Yes, the runtime is credible and widely deployed. But if your plant is standardized on Rockwell or Siemens, that's the wrong question. The real ones are what you give up next to your existing drives and networks, what the second platform costs in people, and who answers the phone when it's down.

Someone on r/PLC asked this one directly: is it worth learning and adopting, or is it just a budget alternative to TIA Portal and Rockwell? I took a swing at it on episode 22. Since then I've gone through the data sheets, the license pages and the CISA advisories, and three things I said on air turned out to be wrong or too strong. I'll flag each one when we get to it.

Here's my basis, so you can weigh it. Colleagues I respect kept bringing CODESYS up, so I took the time to learn it and read about half of the book. Most of my own project work has been on Rockwell and Siemens, and I've covered how those two compare on the show. I have not run very high speed or advanced projects on CODESYS. Where this post leans on documents rather than experience, I say so.

Is CODESYS actually any good?

The runtime is credible: Schneider, WAGO, Festo, Eaton and Opto 22 all ship products on it. Inside a plant standardized on Rockwell or Siemens, the runtime is rarely what decides it. The fit around it does: drives, networks, spares, skills and support. For small and medium machines, that fit can work well.

My general impression is that CODESYS is a reliable solution. The trouble is that PLCs rarely stand alone. They sit next to HMIs, VFDs, servo drives, vision systems and robots, and every one of those has its own way of connecting.

So when someone asks whether it's a budget alternative, I'd separate two things. As a programming environment, it isn't a toy. As a platform to drop into a plant that has spent twenty years building around one vendor, it's a real project with real costs, and few of them are on the license invoice.

From where I sit, CODESYS fits best in small to medium applications. I'm not saying it can't go further. I'm saying I haven't taken it further myself, and you shouldn't take my word for what happens at the high end.

What does "hardware agnostic" really mean?

The language and your logic travel between vendors. The project doesn't simply load onto new hardware. Each target needs its device description installed, the I/O has to be mapped again, and vendors add layers of their own. Treat a hardware change as an engineering task with a retest, not a download.

I'd assumed this would be cleaner than it is. You can't take the program you loaded into an Opto 22, load that same program into a WAGO, and expect to be done. You still need the files for the specific hardware, and you still need to do the mapping.

The documents back that up:

• Device descriptions. CODESYS's online help says a device has to be installed in the Device Repository before you can include it in a project.
• Update Device. This command swaps the device at the same place in the tree. The help says that if the type stays the same, the configuration is kept, and inconsistencies get reported at the next compile. The pages I read don't say what happens to your I/O mapping when the type changes, so test that yourself.
• Vendor layers. Schneider's FAQ FA368090, modified August 2025, says the M241, M251 and M262 can't be programmed directly from CODESYS. They run a CODESYS runtime and still go through Schneider's tool.
• Target limits. Phoenix Contact's March 2026 document allows only one CODESYS application per PLCnext target.

None of that makes the portability fake. Your structured text, your function blocks and most of your architecture come with you. Portability is worth a lot. It just isn't free.

What do you give up next to Rockwell?

CIP Motion, CIP Sync and Device Level Ring, all listed as not supported in CODESYS's own data sheets. EtherNet/IP itself works, with Class 1 and Class 3 messaging and a 1 ms minimum RPI. You also lose the convenience of Rockwell's own drive integration, which is what a Rockwell plant's people already know.

If you've worked in Studio 5000, you know how easy it is to bring in a PowerFlex 525 or a Kinetix drive. The profiles, the UDTs and the AOIs are right there. CODESYS offers connectors too, but that level of integration isn't what you get out of the box.

Here's how it lines up, from the CODESYS EtherNet/IP Scanner and Adapter data sheets and Opto 22's 2021 guide to moving from Rockwell to CODESYS. The term mapping is Opto 22's framing, and Opto 22 sells the alternative, so treat it as a useful starting point rather than an equivalence.

Term mapping gets you started, but the same design problems follow you across. I wrote separately about how AOIs and UDTs turn on you, and a function block library can sprawl the same way.

Opto 22's guide adds a useful warning about the library: a device that isn't fully ODVA compliant may not give you all the data you expected. So if your plant runs on Kinetix over CIP Motion, CODESYS won't drive it that way, and that alone decides those machines. If your line has PowerFlex drives on plain EtherNet/IP I/O, the answer is more open, but you're building by hand what you'd otherwise have downloaded. For more on the wider vendor choice, see the PLC brand debate from an earlier episode.

Can CODESYS handle motion?

Yes, and more than I gave it credit for. One SoftMotion license covers up to 256 real and 256 virtual axes over EtherCAT or CANopen, with cams and gearing. No cycle time is published in those data sheets, though, so a license limit doesn't prove performance. Test your own axis count on your own controller.

This is my first correction. On the episode I said "you cannot synchronize hundreds of drives, you cannot have high-speed control." As an absolute, that's wrong.

The CODESYS SoftMotion Axes data sheet, dated March 2025, says one license controls up to 256 real axes, plus 256 virtual axes on top. It lists electronic cams and gears, PLCopen function blocks, and drive families from Beckhoff, Bosch Rexroth, Festo, Kollmorgen, Omron, Panasonic, Schneider and Yaskawa. The separate CNC and robotics package adds G-code and kinematics up to six axis articulated robots. The EtherCAT Master data sheet lists Distributed Clocks.

What I couldn't find, in the data sheets I read, is a minimum cycle time, a jitter figure, or a table of axes against cycle time. They recommend a target with good real-time behaviour and leave it there. That's fair, because the answer depends on the hardware. But it means 256 is a license ceiling and not a benchmark.

On air I also asked whether a servo drive on CODESYS would match the accuracy of the same drive running natively on Rockwell. I'm still not sure, and nothing I read answers it. It's a measurement you'd make on your own machine, with your own axes, before you commit.

What does CODESYS cost?

The IDE is free and the runtime isn't: it stops after two hours without a license. US store prices ran from $35.00 to $1,139.00 when I checked on November 3, 2026, with fieldbus and motion often sold separately. Hardware vendors bundle differently, and Opto 22 lists one license at $0.00.

Here are the figures, all read on November 3, 2026. The store page has no reliable price date, so check before you budget.

Fieldbus and motion can be extra line items, unless the hardware vendor's package includes them. The PLCnext runtime data sheet, for instance, includes EtherNet/IP, EtherCAT and PROFINET, with SoftMotion as an option. So compare the full bill for your application rather than the entry price.

Here's my position on "budget alternative": the license is the smallest number in this decision. What you save on software and hardware across a machine is real money. A week of an engineer's time learning a new platform on a machine that's down costs more, and that's where I'd spend the analysis.

You may already be running CODESYS

If your plant has Schneider Modicon M-series controllers, WAGO PFCs on CODESYS 3 firmware, Festo controllers or Eaton XC controllers, you probably already run a CODESYS runtime. A shared runtime also means shared security advisories, so find out who patches each of those products, and when, before something forces the question.

This is my second correction. On the episode I contrasted CODESYS with Schneider, as if Schneider were a clean alternative. It isn't that simple. CISA's advisory ICSA-26-020-02, from January 20, 2026, covers Schneider devices using the CODESYS runtime, including Modicon M241, M251, M262, M258 and PacDrive 3. It states that "Many vendors, including Schneider Electric, embed CODESYS in their offers."

The third correction is PLCnext. I said it was "basically CODESYS under the hood." It isn't. PLCnext Technology is Phoenix Contact's own platform, programmed in PLCnext Engineer. CODESYS Control for PLCnext SL is a separately licensed runtime you can add to it.

The other vendors I could confirm:

• WAGO: release notes label PFC100 and PFC200 firmware 04.xx.xx as CODESYS 3.
• Festo and Eaton: CISA advisories for Festo products, and Eaton's XSOFT-CODESYS release notes for the XC303.
• Opto 22: the runtime is preinstalled on groov EPIC PR1 and PR2 processors and three RIO models, according to its October 2026 product guide.

The security point is the one I'd act on. CISA's advisory ICSA-25-273-04, revised November 2025, ties 33 CVEs on Festo CECC controllers to the CODESYS V3 runtime, with no fix planned for many of them on those models. A flaw in a shared runtime reaches many vendors, and each of them patches on its own schedule. List where you have it, then ask each vendor about their process.

Does hardware choice protect you from shortages?

Partly. Rockwell's backlog grew from $2,910,500,000 to $5,197,000,000 between September 2021 and September 2022, and a platform that runs on several vendors' hardware is a real hedge. It only pays off if you've already qualified the second target, because a shortage is a terrible time to start porting.

Rockwell's fiscal 2022 10-K describes a supply chain under stress from demand and pandemic events, and reports those backlog numbers. My own observation from that period is that if you weren't one of the largest manufacturers, you often couldn't get replacement parts. That's what I saw and heard. The filing doesn't say who got parts and who didn't.

So the argument for CODESYS as insurance is fair, and it's probably the best argument a plant manager will hear. But think about what the insurance actually covers. Having CODESYS on one vendor's controller doesn't protect you if that vendor is short too. The protection comes from a second target you've already tested, with its device files, mapping and spares worked out.

Who has to support it?

People are the real constraint. A technician on a Rockwell line can open Studio 5000 and start troubleshooting. A single CODESYS skid means another tool on the laptop, another set of spares, another training plan, and someone who answers at 2 a.m. Budget for those before you budget for hardware.

I'd ask these questions before any technical evaluation:

• Who can go online with it on night shift? Not who could learn it. Who can do it now.
• Which spares sit on the shelf, and who knows which firmware they need?
• Who owns the device files and library versions after the integrator leaves?
• Where does a new hire learn it? Rockwell and Siemens training is everywhere. Yours may be one person.
• Who do you call? The answer may be the hardware vendor, CODESYS or your integrator. Find out which, in writing, before you need them. A Phoenix Contact staff member told one user on the PLCnext forum in 2023 that I/O module support in the CODESYS IDE and runtime was outside their control, which tells you these lines exist.

If those answers are good, CODESYS is an easy decision. If they aren't, the best runtime in the world won't save you from a machine nobody will touch.

When should you pilot CODESYS?

Pilot it on one contained machine or skid with no CIP Motion or DLR dependency, with someone on site who will own it, and test your own cycle time and I/O before anything else. If you can't meet those conditions today, don't pilot it yet. Build the skills first, on a bench.

Here's the rule I'd use:

If you get to a pilot, do these before you sign off on the machine:

1. Measure your real cycle time with your real I/O and axis count, on the actual controller. Don't use the license limit as the number.
2. Connect every peripheral it will run with, and confirm you get the data you need from each one.
3. Move the project to a second target, if hardware choice is part of your reason for doing this. That's the only way to learn what portability costs you.
4. Buy the spares, write the restore procedure, and have someone other than the author restore it.
5. Find out who patches the runtime on that hardware, and how you'd hear about an advisory.
6. Decide in advance what would make you stop, and what would make you do a second machine.

A second platform is a decision about the plant for the next fifteen years, and it isn't a coding choice. If you're weighing it against a wider change, this is part of what a platform migration involves, and it deserves the same discipline.

So, is CODESYS any good? I think so. Whether it's good for your plant depends on what's next to it and who's holding the laptop at 2 a.m.