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: la última objeción contra nuestra respuesta de siempre acaba de caer — y el porqué dice mucho de hacia dónde va la programación de PLCs.

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.

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 de CODESYS — con CODESYS V3.5 SP19 Patch 3 (64-bit) y el paquete de programación para PLC de Raspberry.

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

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é ha caído la última objeción)

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 — nuestra respuesta siempre ha sido la misma: programación abierta y propiedad del código en manos del cliente — Arduino IDE para M-Duino y ESP32 PLC; Node-RED, Node.js, Python y otras tecnologías abiertas para el Raspberry Pi PLC. La objeción clásica que nos ponían era razonable: "un programa IEC 61131-3 lo continúa cualquier profesional de la automatización; vuestro código depende de quien lo escribió". Hoy esa objeción ha dejado de existir.

Hoy el ganador absoluto es programar con IA sobre herramientas abiertas — no porque hayamos cambiado de respuesta, sino porque la IA ha tumbado esa objeción y nos ha dado la razón. El viejo compromiso del código — la opción más potente, pero la más lenta de desarrollar y la más dependiente de su autor original — se ha invertido. Con un asistente de IA, escribir C/C++ para un M-Duino o ESP32 PLC en Arduino IDE, o Python y Node.js en un Raspberry Pi PLC, es rápido: el asistente redacta, explica, refactoriza y documenta en minutos lo que antes costaba días. Y la pregunta del principio — ¿quién mantiene esto en cinco años? — también se da la vuelta: los lenguajes abiertos mayoritarios son justo lo que mejor leen y explican los asistentes de IA, así que quien herede el código no lo heredará solo. El código abierto es hoy la opción más potente y la más rápida, sin licencias de runtime y sin un entorno cerrado entre tú y tu máquina.

Que las herramientas abiertas ganen "en general" no significa que ganen en tu caso. Node-RED sigue siendo imbatible para lo que nació — flujos visuales sencillos: una pasarela, un dashboard, una tubería de datos montada en una tarde. Y CODESYS conserva un nicho honesto: si tu equipo ya está estandarizado en IEC 61131-3, o migras lógica desde PLCs clásicos, sigue siendo el camino más corto — un entorno cerrado y con licencia es el precio de esa compatibilidad, y a esos equipos les suele compensar. 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

1. ¿La lógica es control secuencial de máquina? → descarta Node-RED para esa parte.
2. ¿Hay requisitos de tiempo de ciclo estrictos? → Arduino IDE o CODESYS.
3. ¿Fabricas en serie y el coste por unidad importa? → Arduino IDE toma ventaja.
4. ¿Tu equipo viene de PLCs tradicionales? → CODESYS toma ventaja.
5. ¿El grueso del proyecto es datos, integración y visualización? → Node-RED toma ventaja.
6. ¿Quién mantendrá el programa en 5 años no es quien lo escribe hoy? → un código versionado y documentado, con asistencia de IA, lo cubre; CODESYS sigue siendo la opción segura si quien lo mantiene solo habla IEC 61131-3.
7. ¿Programas con un asistente de IA al lado? → el código abierto — Arduino IDE, o Python/Node.js en el Raspberry Pi PLC — toma la ventaja general.

📥 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.

Descargar la guía gratuita →

¿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.