Node-RED vs CODESYS vs Arduino IDE: el ranking honesto para programar tu PLC
Hay tres formas principales de programar un PLC industrial open source, y la pregunta "¿cuál es mejor?" llega a nuestro soporte técnico cada semana. La respuesta corta no existe, y quien te la dé sin preguntarte nada antes te está vendiendo su herramienta, no resolviendo tu problema.
La respuesta larga sí existe, y es la que vas a leer aquí: qué hace bien cada entorno, dónde está su techo real, cómo quedan clasificados según el perfil de tu equipo y de tu proyecto — y al final, el ganador absoluto si solo pudiéramos quedarnos con uno para el proyecto industrial típico. Aviso desde ya: esa última respuesta incomoda a una parte de nuestros propios clientes.
Todo el ranking se decide con una sola pregunta que casi nadie se hace al principio: ¿quién va a mantener este programa dentro de cinco años? Tenla presente mientras lees.
Los tres contendientes, en profundidad
Arduino IDE (C/C++): control absoluto, responsabilidad absoluta
Programar un PLC con Arduino IDE significa escribir C/C++ que se compila directamente contra el microcontrolador. Sin sistema operativo, sin runtime intermedio, sin licencias por unidad. Es el entorno nativo de nuestras familias M-Duino y ESP32 PLC.
Lo que hace mejor que nadie:
- Determinismo y rendimiento. El código compilado corre a un ciclo de máquina del silicio. Tiempos de respuesta predecibles, arranque en milisegundos, acceso directo a interrupciones y periféricos. Es el techo de rendimiento más alto de los tres.
- Coste cero por unidad. No hay licencia de runtime. Para un OEM que fabrica 200 máquinas al año, esto no es un detalle: es margen directo.
- El código es tuyo. Un repositorio Git con tu firmware es un activo de empresa: versionable, auditable, sin dependencia de ningún proveedor de software.
Dónde está su techo:
- Todo es posible y nada viene hecho. Cada protocolo, cada reconexión de bus, cada estado seguro, cada watchdog lo implementas tú o lo delegas en librerías que tú eliges, versionas y mantienes.
- Mantenibilidad dependiente de personas. Un programa en C/C++ bien estructurado es mantenible; el problema es que "bien estructurado" depende de quién lo escribió. Si esa persona se va, el siguiente hereda un firmware que puede tardar semanas en entender. Es el famoso bus factor.
- Depuración en planta. No hay depuración online estándar como en un PLC tradicional: trabajas con logs por puerto serie y con la instrumentación que tú mismo hayas previsto.
Node-RED (flujos + JavaScript): la integración como superpoder
Node-RED es programación visual por flujos sobre Node.js, y su casa natural es el Raspberry Pi PLC, donde se instala y corre sobre Linux igual que en cualquier Raspberry Pi — no viene preinstalado, pero hay guía oficial de instalación y de ejecución como servicio con autoarranque: https://www.industrialshields.com/blog/raspberry-pi-for-industry-26/how-to-install-node-red-onto-a-raspberry-pi-plc-panel-pc-448
Lo que hace mejor que nadie:
- Integración a velocidad récord. Existen nodos mantenidos por la comunidad para Modbus RTU/TCP, MQTT, OPC-UA, bases de datos SQL, InfluxDB, dashboards web, correo, Telegram… Una pasarela completa de planta — leer 10 esclavos Modbus, historizar en base de datos y publicar por MQTT — se monta en una tarde. Literalmente.
- Curva de entrada suavísima. Un técnico sin formación formal en programación entiende un flujo bien hecho a la primera. Para supervisión y datos, es el entorno más democrático de los tres.
- Dashboards incluidos. Con los nodos de dashboard tienes un HMI web servido desde el propio PLC sin escribir una línea de HTML.
Dónde está su techo:
- La lógica de control compleja degenera. Una secuencia de máquina con 15 estados, enclavamientos y gestión de fallos expresada en flujos se convierte en un plato de espaguetis visual imposible de auditar. Quien lo ha sufrido sabe que no exageramos.
- No es determinista. Corre sobre Node.js sobre Linux: el planificador del sistema operativo y el recolector de basura de JavaScript mandan. Para telemetría e integración es irrelevante; para un lazo de control con requisitos de tiempo, es descalificante.
- Versionado incómodo. Los flujos son JSON exportable, pero un diff de Git sobre ese JSON es difícil de revisar. La disciplina de versiones exige método propio.
CODESYS (IEC 61131-3): el idioma que habla toda la industria
CODESYS es el entorno estándar de facto de la automatización industrial: Ladder, texto estructurado (ST), bloques de función (FBD) y SFC, todo bajo la norma IEC 61131-3. En nuestra gama corre sobre el Raspberry Pi PLC (basado en Raspberry Pi 4B), y publicamos la guía oficial de configuración — con CODESYS V3.5 SP19 Patch 3 (64-bit) y el paquete de programación para PLC de Raspberry: https://www.industrialshields.com/blog/raspberry-pi-for-industry-26/setting-up-codesys-for-raspberry-pi-plc-in-industrial-automation-640
Lo que hace mejor que nadie:
- Cualquier programador de PLCs del planeta lo lee. Si mañana tu integrador desaparece, contratas a otro que venga de Siemens, Schneider u Omron y en una semana está productivo. Ningún otro entorno de esta lista ofrece eso.
- Gestión de tareas industrial. Tareas cíclicas con tiempos definidos y supervisados, prioridades, watchdog de tarea integrado. La estructura que un programa de máquina serio necesita viene de serie.
- Depuración online. Ver variables en vivo, forzar salidas, modificar lógica con la máquina en marcha (con criterio). Es la herramienta de puesta en marcha más potente de las tres, y en planta se nota cada hora.
- Ruta de migración. Lógica existente en un PLC tradicional escrita en Ladder o ST se porta con esfuerzo razonable.
Dónde está su techo:
- Licencia de runtime. A diferencia de los otros dos, el runtime CODESYS tiene sus propias condiciones de licencia, que fija CODESYS GmbH según la modalidad elegida. Para una instalación única suele ser un detalle; para una serie de máquinas, verifica las condiciones vigentes antes de cerrar el escandallo.
- Una capa más entre tú y el hardware. El acceso a periféricos pasa por el runtime; lo exótico (un sensor raro por SPI, una interrupción de alta frecuencia) puede quedar fuera de su alcance directo.
- Integración IT menos ágil. ¿Se puede hablar con una base de datos o publicar MQTT desde CODESYS? Sí. ¿Es tan directo como en Node-RED? No.
La tabla comparativa
| Criterio | Arduino IDE | Node-RED | CODESYS |
|---|---|---|---|
| Determinismo / tiempo de ciclo | Máximo (sin OS, compilado) | Bajo (Node.js sobre Linux) | Alto (tareas cíclicas supervisadas) |
| Curva de aprendizaje (perfil automatización) | Media-alta | Media | Baja |
| Curva de aprendizaje (perfil software/IT) | Media | Baja | Media-alta |
| Coste de licencias por unidad | Cero | Cero | Runtime con licencia (condiciones según CODESYS) |
| Lógica secuencial de máquina | Buena (si hay disciplina) | Mala en cuanto crece | Excelente (SFC, ST) |
| Integración datos/IT (MQTT, BD, dashboards) | Manual, laboriosa | Excelente | Correcta, menos ágil |
| Depuración en planta | Logs serie, instrumentación propia | Nodos debug, inyección en vivo | Online: variables en vivo, forzados |
| Mantenibilidad por terceros | Depende del autor | Buena en flujos pequeños | La mejor: estándar universal |
| Coste total de propiedad en serie (OEM) | El más bajo | Baja | Licencias × unidades |
El ranking, perfil a perfil
El "mejor" entorno depende de dos ejes: de dónde viene tu equipo y qué hace tu proyecto. Clasificamos de peor a mejor para cada caso.
Si vienes de la automatización clásica (Siemens, Schneider, Omron)
Peor → mejor: Arduino IDE → Node-RED → CODESYS.
Tu equipo ya piensa en IEC 61131-3: Ladder, ST, bloques de función. Obligarle a reescribir su mentalidad en C/C++ es tirar años de experiencia. CODESYS le permite ser productivo el primer día y conservar sus patrones de diagnóstico. Node-RED queda segundo como complemento para la capa de datos, no para el control.
Si vienes del software / IT
Peor → mejor: CODESYS → Arduino IDE → Node-RED.
JavaScript, Git, APIs, bases de datos: todo tu instinto juega a favor de Node-RED. Para proyectos donde el PLC es sobre todo pasarela, concentrador de datos o supervisión, ganarás una velocidad que a un programador de PLCs clásico le parecería ciencia ficción. Cuidado con la trampa: si el proyecto deriva hacia control secuencial serio, planifica esa parte fuera de los flujos.
Si eres OEM y el PLC va dentro de tu máquina en serie
Peor → mejor: Node-RED → CODESYS → Arduino IDE.
Aquí mandan tres cosas: coste por unidad (cero licencias), control total del firmware (tu producto no depende de un runtime de terceros) y propiedad intelectual (tu código es un activo). Arduino IDE gana con claridad — con una condición innegociable: disciplina de ingeniería de software. Repositorio, revisiones de código, documentación. El OEM que no puede garantizar eso debería pensarse el segundo puesto.
Y el eje que falta: qué hace tu proyecto
- Control puro de máquina o proceso (secuencias, enclavamientos, dosificación): CODESYS o Arduino IDE. Node-RED, no.
- Datos, pasarelas, historización, dashboards: Node-RED sin discusión.
- Ambas cosas: la arquitectura ganadora suele ser dos capas: el control en CODESYS o Arduino IDE y la capa de datos en Node-RED — a veces en el mismo Raspberry Pi PLC, a veces repartido entre un M-Duino (control) y un Raspberry Pi PLC (datos).
El ganador absoluto (y por qué incomoda)
Prometimos mojarnos: si solo pudiéramos quedarnos con un entorno para el proyecto industrial típico — una máquina o proceso de complejidad media, que debe funcionar años, mantenida por personas que probablemente no serán las que la programaron — el ganador es CODESYS.
Sabemos que incomoda. Industrial Shields nació del ecosistema Arduino y una parte importante de nuestros clientes nos eligió precisamente por programar sin licencias ni entornos corporativos. Pero el criterio que decide no es el cariño a la herramienta: es la pregunta del principio. ¿Quién mantiene esto en cinco años? El proyecto industrial típico sobrevive a su programador original, y el único de los tres entornos que garantiza que cualquier profesional de la automatización pueda continuarlo es el que habla el estándar de la industria.
Que gane CODESYS "en general" no significa que gane en tu caso. Los perfiles de arriba están para eso: el OEM en serie tiene razones económicas y estratégicas de peso para Arduino IDE, y el proyecto de datos puro se hace en Node-RED en una fracción del tiempo. El error no es elegir cualquiera de los tres; el error es elegir por familiaridad sin haberse hecho las dos preguntas: quién mantiene y qué hace el proyecto.
La ventaja de la gama de Industrial Shields es que no te obliga a casarte: en el Raspberry Pi PLC puedes instalar y ejecutar Node-RED y CODESYS — ambos con guía oficial publicada —, y los M-Duino y ESP32 PLC se programan con Arduino IDE. Mismo catálogo, tres filosofías, y la posibilidad de combinarlas.
Decide en cinco minutos: el checklist
- ¿La lógica es control secuencial de máquina? → descarta Node-RED para esa parte.
- ¿Hay requisitos de tiempo de ciclo estrictos? → Arduino IDE o CODESYS.
- ¿Fabricas en serie y el coste por unidad importa? → Arduino IDE toma ventaja.
- ¿Tu equipo viene de PLCs tradicionales? → CODESYS toma ventaja.
- ¿El grueso del proyecto es datos, integración y visualización? → Node-RED toma ventaja.
- ¿Quién mantendrá el programa en 5 años no es quien lo escribe hoy? → CODESYS toma ventaja decisiva.
📥 Descarga la checklist: De prototipo Arduino a instalación industrial
La guía completa que resume las 12 semanas de "De Prototipo a Planta": selección de plataforma y entorno de programación, cableado, comunicaciones, componentes, marcado CE y cronología realista. El documento que nos habría gustado tener al empezar.
¿Quieres probar los tres entornos sobre el mismo hardware? El Raspberry Pi PLC (con Raspberry Pi 4B y Linux, sin coste de licencia de la plataforma) admite Node-RED y CODESYS, y convive con M-Duino y ESP32 PLC programados en Arduino IDE: https://www.industrialshields.com/industrial-hardware-solutions-based-on-raspberry-pi