Complete guide: How to choose an industrial controller
Arduino PLC vs ESP32 PLC vs Raspberry Pi PLC: which one should you choose?
Choose an Arduino based PLC (M-Duino, ATmega2560, no operating system) for pure machine control with Modbus. Choose an ESP32 PLC (dual-core ESP32 at 240 MHz, Wi-Fi and Bluetooth LE built in) for control plus wireless telemetry and MQTT. Choose a Raspberry Pi PLC (Linux, 2, 4 or 8 GB of RAM) for data, gateways, HMI and edge computing. If the process cannot wait the tens of seconds that Linux needs to boot after a power cut, keep the control on a microcontroller.
A common selection mistake we see in technical support is choosing by familiarity ("I already know Arduino") instead of the real requirements of the installation. This guide compares the three families on the same criteria, explains the power-cut test that rules one of them out of the controller role, and lists the three costliest mistakes.
- Pure controlArduino PLCM-Duino: I/O, logic and Modbus, millisecond boot
- Control and IIoTESP32 PLCWi-Fi, Bluetooth LE and MQTT in the controller
- Data and edgeRaspberry Pi PLCLinux: Node-RED, Python, databases, HMI
- Check firstPower cutsCan the process wait for Linux to boot?
Comparison table: Arduino PLC, ESP32 PLC and Raspberry Pi PLC
| Criterion | Arduino PLC (M-Duino) | ESP32 PLC | Raspberry Pi PLC |
|---|---|---|---|
| Processor | Arduino Mega 2560 (ATmega2560, 8-bit, 16 MHz) | ESP32, dual-core, up to 240 MHz | Raspberry Pi with Linux |
| Memory | 8 KB SRAM, 256 KB flash | 520 KB internal SRAM | 2, 4 or 8 GB RAM (configurable models) |
| Operating system | None | None | Linux |
| Determinism | Predictable loop if the code does not block | Predictable loop if the code does not block | Depends on system load |
| Boot after a power cut | Milliseconds | Milliseconds | Tens of seconds; built-in UPS for an orderly shutdown |
| Communications | Ethernet, RS-485, RS-232, I2C, SPI, RTC | Ethernet, Wi-Fi, Bluetooth LE, RS-485, I2C; RS-232 and SPI except on the 14; LoRa or 4G option board | 2 x Ethernet, RS-485, Wi-Fi, Bluetooth LE, I2C, SPI, RTC |
| I/O range | From 6 inputs and 11 outputs (19R) to 36 inputs and 22 outputs (58) | From 9 inputs and 5 outputs (14) to 37 inputs and 24 outputs (58) | From 6 inputs and 11 outputs (19R) to 39 inputs and 24 outputs (58) |
| Programming | Arduino IDE (C/C++), OpenPLC | Arduino IDE (C/C++), OpenPLC | Python, Node-RED, C++, CODESYS |
| HMI, historian, databases | No | Very limited | Yes, its main strength |
| Typical use | Machine control and Modbus networks | Control plus wireless telemetry and MQTT | Edge computing, gateways, local HMI |
Data from the product sheets; check the exact model before you specify it. All three families are DIN-rail mounted, powered at 12 to 24 Vdc, with protected I/O.
When should you choose an Arduino PLC (M-Duino)?
An M-Duino has an original Arduino Mega 2560 inside: no operating system, a boot in milliseconds, a predictable cycle and no surprises after a power cut. The program you uploaded is exactly what runs, cycle after cycle.
The right choice when the job is pure control: read inputs, run the logic, drive outputs and talk Modbus RTU or TCP to drives and sensors. Process machines, dosing, pumping and simple lines. Fewer layers between the code and the hardware means fewer things that can fail at 3 a.m. The models are named after their total I/O: the M-Duino 21+, for example, has 13 inputs (6 analog 0-10 V) and 8 outputs (3 analog or PWM).
Where it falls short: an embedded HMI, local databases or data processing on the device. With 8 KB of SRAM you would be fighting the platform.
Start with the Modbus RTU guide for Arduino and ESP32 based PLCs.
When should you choose an ESP32 PLC?
The ESP32 PLC keeps the microcontroller approach (no operating system, predictable loop) and adds what the ATmega2560 lacks: Wi-Fi and Bluetooth LE built in, two cores at up to 240 MHz and 520 KB of internal SRAM.
The right choice for IIoT: telemetry over MQTT to a broker, remote nodes where an Ethernet cable is expensive or impossible, and retrofits that take data from old machines without touching their original control. Also when the control logic needs more computing than an ATmega2560 offers, without a full operating system.
Where it falls short: Wi-Fi in a plant is a telemetry link, not a control bus. Interference, roaming and a crowded spectrum are outside your control. Telemetry over Wi-Fi: yes. Interlocks over Wi-Fi: never.
When should you choose a Raspberry Pi PLC?
Here the approach changes: Linux, gigabytes of RAM, and Node-RED, Python, local databases, OPC UA gateways and dashboards served from the PLC itself.
The right choice when the PLC has to control and also process data: a data concentrator for several machines, a Modbus to MQTT or OPC UA gateway, a local historian, light machine vision or a web HMI for the operator's tablet. One DIN-rail unit does the job of a PLC plus an industrial PC.
Where it falls short: an operating system needs discipline: orderly shutdowns, control of disk writes and watchdogs. The Raspberry PLC has a built-in UPS that rides through short drops and, in a long outage, shuts the system down in order, so the file system is not corrupted. What the UPS cannot remove is the boot time: after a long outage, Linux takes tens of seconds to start. A control loop that cannot wait that long belongs on an M-Duino or an ESP32 PLC, with the Raspberry PLC as the data layer. For hard real-time loops, a microcontroller is also simpler to justify in a risk assessment.
IEC 61131-3 on this family is possible with CODESYS: see Setting up CODESYS for the Raspberry PLC.
What happens when the power fails?
This is the criterion almost nobody checks, and it can rule out one family from the controller role: how the device behaves in an uncontrolled power loss.
A microcontroller (Arduino PLC, ESP32 PLC) tolerates power cuts by design: there is no file system to corrupt and no shutdown to respect. Power comes back, it boots in milliseconds and the program runs from the start.
A Linux device that boots from an SD card is different. A cut in the middle of a write can corrupt the file system, and the symptom appears later: the device does not boot again, weeks after the cut that caused the damage. Even when everything goes well, the boot takes tens of seconds, and during that time the outputs are in the state the hardware sets, not the state your logic sets.
That does not make the Raspberry Pi PLC unfit for the plant; it means it needs design. The built-in UPS absorbs short drops and, in a long outage, triggers the orderly shutdown by itself, with no external DIN-rail UPS. The rest is yours: a read-only file system (overlay) for the system partition, an industrial SD card and important logs sent to a server, not to the card.
The test question is: after a long outage, can the process wait the tens of seconds Linux needs to boot? If not, the controller role goes to a microcontroller, and the Raspberry Pi PLC stays in the architecture as the data layer: if it reboots, the machine does not notice.
The 3 costliest selection mistakes
Mistake 1: overspecifying "just in case"
Choosing a Raspberry Pi PLC for pure machine control "because it is more powerful". The result is all the work of maintaining a Linux system (images, updates, SD cards) to run logic that an M-Duino would run for years without attention. Power you do not need is not margin; it is failure surface and maintenance cost.
Mistake 2: underspecifying out of familiarity
The opposite, and the most common one: choosing an Arduino PLC "because I already know Arduino" and finding out at commissioning that the customer wants a data historian, a screen and reports. What follows is patches, such as a "temporary" desktop PC that stays for years, or a redesign of a machine already sold. Ask for the data requirements before you choose the platform.
Mistake 3: trusting control to Wi-Fi
Choosing an ESP32 PLC and using the wireless link as the control bus between the PLC and the actuators. It works in the demo. In the plant, with many overlapping networks and metal forklifts moving between antenna and device, the link drops and the machine stops. The rule: data that can arrive late travels over Wi-Fi; anything whose absence stops or damages the machine travels over a cable.
Decide in 5 questions
- Does the device need to store or process data locally (historian, HMI, gateway)? Yes: Raspberry Pi PLC. No: go on.
- Do you need wireless connectivity built in (MQTT, remote nodes)? Yes: ESP32 PLC. No: go on.
- Is the job pure control with Modbus and I/O? Arduino PLC.
- Are there frequent power cuts and a process that cannot wait for a Linux boot? Keep Linux out of the controller role.
- Who will maintain the device in five years, and what do they program in? If two families tie, the team breaks the tie. See Node-RED vs CODESYS vs Arduino IDE.
The three families share open-source programming, DIN-rail mounting and industrial protections. Choosing the wrong family within the catalog is fixed by migrating; installing a bare prototype board in the panel is paid in full.
FAQ about Arduino, ESP32 and Raspberry Pi PLCs
Is an Arduino, ESP32 or Raspberry Pi based controller a real industrial PLC?
It does the job of a PLC: it reads industrial inputs, runs the logic and drives outputs from a DIN-rail unit with protected I/O. What changes is the programming and the certifications, which you must check model by model against your specification.
Can I program these PLCs in Ladder?
Yes. M-Duino, Ardbox and ESP32 PLC can be programmed with OpenPLC, and the Raspberry PLC runs CODESYS. You can also use the Arduino IDE, Python or Node-RED.
Can an ESP32 PLC control a machine over Wi-Fi?
It can send and receive data over Wi-Fi, but interlocks and anything that stops or protects the machine should travel over a cable. Use Wi-Fi for telemetry.
Which family is best for a Modbus to MQTT gateway?
The Raspberry Pi PLC, or the GateBerry if no local I/O is needed: both run Node-RED on Linux. An ESP32 PLC can also publish its own Modbus readings over MQTT when the volume is small.
Can I combine families in one installation?
Yes, and it is common: an M-Duino or ESP32 PLC runs the machine and a Raspberry PLC collects the data over Modbus TCP or MQTT. The guide to Modbus RTU, Modbus TCP and OPC UA shows which protocol goes at each level.
New option
A microcontroller and Linux in one PLC: Ardbox Q
If your project needs real-time control and a Linux side for data, dashboards or communications, Ardbox Q combines both: an STM32 microcontroller programmed with the Arduino IDE and Debian Linux on a separate processor. Analog version with 19 I/O and Relay version with 20 I/O.
Take it further
Not sure which family fits? See each one at work: an Arduino PLC in a test case, an ESP32 PLC and a Raspberry PLC in simulators.
Case study · Arduino PLC
Test every unit. Keep the result.
An M-Duino 42 runs the test steps and records OK or KO for each serial number, with the date from the RTC and the result stored on the SD.
Read the case study
Simulator · ESP32 PLC
Count who comes in and who goes out, and turn the light red at the limit
An ESP32 PLC 21 CORE reads two beams or two loops at each entrance and tells entries from exits.
Open the simulator
Simulator · Raspberry PLC
Keep a cold room in its band, door, defrost and power cut included
A Raspberry PLC 21 runs the compressor, the fans and the defrost, and keeps the record that proves the cold chain.
Open the simulator
Compare with classic PLCs and industrial PCs too. The controller guide compares four controller types on eight criteria and says when an Industrial Shields controller is not the right choice.
Choose an industrial controllerSee the PLC range
Taking an Arduino prototype to the plant? Download the free checklist "From Arduino prototype to industrial installation": 12 steps in a printable PDF. Still between two families? Write to us with your I/O, communications and environment, and an engineer will tell you which one fits, including when none does.