Node-RED vs CODESYS vs Arduino IDE: the honest ranking for programming your PLC

There are three main ways to program an open source industrial PLC, and the question "which one is best?" reaches our technical support every week. There's no short answer, and whoever gives you one without asking anything first is selling you their tool, not solving your problem.

The long answer does exist, and it's what you're about to read: what each environment does well, where its real ceiling is, how they rank depending on your team's profile and your project — and at the end, the absolute winner if we could only keep one for the typical industrial project. Fair warning: that last answer will make some of our own customers uncomfortable.

The whole ranking comes down to one question almost nobody asks at the start: who is going to maintain this program five years from now? Keep it in mind as you read.

The three contenders, in depth

Arduino IDE (C/C++): total control, total responsibility

Programming a PLC with Arduino IDE means writing C/C++ that compiles directly against the microcontroller. No operating system, no intermediate runtime, no per-unit licenses. It's the native environment of our M-Duino and ESP32 PLC families.

What it does better than anyone:

• Determinism and performance. Compiled code runs at the silicon's machine cycle. Predictable response times, millisecond startup, direct access to interrupts and peripherals. It's the highest performance ceiling of the three.
• Zero cost per unit. There's no runtime license. For an OEM manufacturing 200 machines a year, that's not a footnote — it's direct margin.
• The code is yours. A Git repository with your firmware is a company asset: versionable, auditable, with no dependency on any software vendor.

Where its ceiling is:

• Everything is possible, and nothing comes built-in. Every protocol, every bus reconnection, every safe state, every watchdog is something you implement yourself or delegate to libraries you choose, version, and maintain.
• Maintainability depends on people. A well-structured C/C++ program is maintainable; the problem is that "well-structured" depends on who wrote it. If that person leaves, the next one inherits firmware that can take weeks to understand. It's the famous bus factor.
• Debugging on the plant floor. There's no standard online debugging like on a traditional PLC: you work with serial-port logs and whatever instrumentation you built in yourself.

Node-RED (flows + JavaScript): integration as a superpower

Node-RED is visual flow-based programming on top of Node.js, and its natural home is the Raspberry Pi PLC, where it installs and runs on Linux just like on any Raspberry Pi — it doesn't come pre-installed, but there's an official guide for installing it and running it as an auto-starting service: https://www.industrialshields.com/blog/raspberry-pi-for-industry-26/how-to-install-node-red-onto-a-raspberry-pi-plc-panel-pc-448

What it does better than anyone:

• Record-speed integration. There are community-maintained nodes for Modbus RTU/TCP, MQTT, OPC-UA, SQL databases, InfluxDB, web dashboards, email, Telegram… A complete plant gateway — reading 10 Modbus slaves, historizing to a database, and publishing over MQTT — comes together in an afternoon. Literally.
• A very gentle learning curve. A technician with no formal programming background understands a well-built flow on the first try. For monitoring and data, it's the most democratic environment of the three.
• Dashboards included. With the dashboard nodes you get a web HMI served straight from the PLC itself, without writing a single line of HTML.

Where its ceiling is:

• Complex control logic degenerates. A machine sequence with 15 states, interlocks, and fault handling expressed as flows turns into a visual spaghetti plate that's impossible to audit. Anyone who's been through it knows we're not exaggerating.
• It's not deterministic. It runs on Node.js on top of Linux: the OS scheduler and the JavaScript garbage collector call the shots. For telemetry and integration that's irrelevant; for a control loop with timing requirements, it's disqualifying.
• Awkward versioning. Flows export as JSON, but a Git diff on that JSON is hard to review. Version discipline requires its own method.

CODESYS (IEC 61131-3): the language the whole industry speaks

CODESYS is the de facto standard environment of industrial automation: Ladder, Structured Text (ST), Function Block Diagram (FBD), and SFC, all under the IEC 61131-3 standard. In our range it runs on the Raspberry Pi PLC (based on the Raspberry Pi 4B), and we publish the official setup guide — with CODESYS V3.5 SP19 Patch 3 (64-bit) and the programming package for the Raspberry Pi PLC: https://www.industrialshields.com/blog/raspberry-pi-for-industry-26/setting-up-codesys-for-raspberry-pi-plc-in-industrial-automation-640

What it does better than anyone:

• Any PLC programmer on the planet can read it. If your integrator disappears tomorrow, you hire someone else coming from Siemens, Schneider, or Omron, and they're productive within a week. None of the other environments on this list offers that.
• Industrial task management. Cyclic tasks with defined, supervised timing, priorities, built-in task watchdog. The structure a serious machine program needs comes standard.
• Online debugging. Watch variables live, force outputs, modify logic with the machine running (with judgment). It's the most powerful commissioning tool of the three, and it shows every hour on the plant floor.
• Migration path. Existing logic on a traditional PLC written in Ladder or ST ports over with reasonable effort.

Where its ceiling is:

• Runtime license. Unlike the other two, the CODESYS runtime carries its own licensing terms, set by CODESYS GmbH depending on the chosen model. For a single installation it's usually a non-issue; for a machine series, check the current terms before closing your cost breakdown.
• One more layer between you and the hardware. Peripheral access goes through the runtime; the exotic stuff (an unusual SPI sensor, a high-frequency interrupt) can fall outside its direct reach.
• Less agile IT integration. Can CODESYS talk to a database or publish over MQTT? Yes. Is it as direct as in Node-RED? No.

The comparison table

The ranking, profile by profile

The "best" environment depends on two axes: where your team comes from and what your project does. We rank from worst to best for each case.

If you come from classic automation (Siemens, Schneider, Omron)

Worst → best: Arduino IDE → Node-RED → CODESYS.

Your team already thinks in IEC 61131-3: Ladder, ST, function blocks. Forcing them to rewrite their mindset in C/C++ throws away years of experience. CODESYS lets them be productive from day one and keep their diagnostic patterns. Node-RED comes second as a complement for the data layer, not for control.

If you come from software / IT

Worst → best: CODESYS → Arduino IDE → Node-RED.

JavaScript, Git, APIs, databases: all your instincts favor Node-RED. For projects where the PLC is mainly a gateway, data concentrator, or supervisory layer, you'll gain a speed that a classic PLC programmer would find like science fiction. Watch the trap: if the project drifts toward serious sequential control, plan that part outside the flows.

If you're an OEM and the PLC goes inside your series-built machine

Worst → best: Node-RED → CODESYS → Arduino IDE.

Here three things rule: cost per unit (zero licenses), full control of the firmware (your product doesn't depend on a third-party runtime), and intellectual property (your code is an asset). Arduino IDE clearly wins — with one non-negotiable condition: software engineering discipline. Repository, code reviews, documentation. The OEM that can't guarantee that should reconsider second place.

And the missing axis: what your project does

• Pure machine or process control (sequences, interlocks, dosing): CODESYS or Arduino IDE. Not Node-RED.
• Data, gateways, historization, dashboards: Node-RED, no contest.
• Both: the winning architecture is usually two layers: control in CODESYS or Arduino IDE and the data layer in Node-RED — sometimes on the same Raspberry Pi PLC, sometimes split between an M-Duino (control) and a Raspberry Pi PLC (data).

The absolute winner (and why it's uncomfortable)

We promised to commit: if we could only keep one environment for the typical industrial project — a machine or process of medium complexity, meant to run for years, maintained by people who probably weren't the ones who programmed it — the winner is CODESYS.

We know it's uncomfortable. Industrial Shields was born from the Arduino ecosystem, and a good share of our own customers chose us precisely to program without licenses or corporate environments. But the deciding criterion isn't attachment to a tool: it's the question from the start. Who maintains this in five years? The typical industrial project outlives its original programmer, and the only one of the three environments that guarantees any automation professional can pick it up is the one that speaks the industry standard.

CODESYS winning "in general" doesn't mean it wins in your case. The profiles above exist for exactly that: the series-production OEM has solid economic and strategic reasons for Arduino IDE, and a pure data project gets built in Node-RED in a fraction of the time. The mistake isn't choosing any of the three; the mistake is choosing out of familiarity without asking the two questions: who maintains it, and what does the project do.

The advantage of the Industrial Shields range is that it doesn't force you to commit to just one: on the Raspberry Pi PLC you can install and run both Node-RED and CODESYS — each with an official published guide —, and the M-Duino and ESP32 PLC are programmed with Arduino IDE. Same catalog, three philosophies, and the option to combine them.

Decide in five minutes: the checklist

1. Is the logic sequential machine control? → rule out Node-RED for that part.
2. Are there strict cycle-time requirements? → Arduino IDE or CODESYS.
3. Are you manufacturing in series and does per-unit cost matter? → Arduino IDE takes the lead.
4. Does your team come from traditional PLCs? → CODESYS takes the lead.
5. Is most of the project data, integration, and visualization? → Node-RED takes the lead.
6. Will whoever maintains the program in 5 years not be who wrote it today? → CODESYS takes the decisive lead.

📥 Download the checklist: From Arduino prototype to industrial installation

The complete guide summarizing the 12 weeks of "From Prototype to Plant": platform and programming environment selection, wiring, communications, components, CE marking, and a realistic timeline. The document we wish we'd had when we started.

Download the free guide →

Want to try all three environments on the same hardware? The Raspberry Pi PLC (with Raspberry Pi 4B and Linux, no platform licensing cost) supports Node-RED and CODESYS, and it coexists with M-Duino and ESP32 PLC programmed in Arduino IDE: https://www.industrialshields.com/industrial-hardware-solutions-based-on-raspberry-pi