Por qué existe un estándar de lenguajes para PLC
Antes de la norma IEC 61131-3 (publicada en 1993), cada fabricante de PLC tenía su propio lenguaje de programación, muchas veces incompatible incluso entre distintas gamas del mismo fabricante. Un programa escrito para un controlador no se podía llevar a otro sin reescribirlo entero, y formar a un programador nuevo significaba formarlo en una marca concreta, no en una disciplina. La norma resolvió esto definiendo cinco lenguajes de programación estandarizados, con una sintaxis, unos tipos de datos y un modelo de ejecución comunes, que hoy implementan prácticamente todos los entornos de programación de autómatas programables del mercado, desde Codesys hasta TIA Portal.
Que un lenguaje esté estandarizado no significa que todos sirvan para lo mismo. La norma no busca que un programador elija uno y lo use para todo, sino que cada tarea de un proyecto se resuelva con el lenguaje que mejor se ajusta a su naturaleza. Esa es la idea central de este artículo.
Los cinco lenguajes de la norma IEC 61131-3
La norma agrupa los lenguajes en dos familias: gráficos, que representan la lógica como un diagrama, y textuales, que la representan como código escrito. La tabla resume las cinco opciones y su uso más habitual en planta:
| Lenguaje | Tipo | Uso típico |
|---|---|---|
| Ladder Diagram (LD) | Gráfico | Lógica combinacional, enclavamientos, seguridad |
| Function Block Diagram (FBD) | Gráfico | Regulación continua, lazos PID, señales analógicas |
| Sequential Function Chart (SFC) | Gráfico | Secuencias de proceso, máquinas de estados, procesos por lotes |
| Structured Text (ST) | Textual | Algoritmos, cálculo matemático, gestión de arrays y recetas |
| Instruction List (IL) | Textual | Herencia de programas antiguos; en desuso desde 2013 |
Ladder Diagram (LD): el lenguaje universal
Ladder es, con diferencia, el lenguaje más extendido en la industria, y su forma se explica por su origen: representa la lógica como un diagrama de contactos y bobinas que imita los esquemas de relés electromecánicos que sustituyó en los años setenta. Esa herencia es justamente su fortaleza: cualquier electricista de mantenimiento, sin formación en programación, puede seguir la lógica de un enclavamiento leyendo el diagrama como si fuera un esquema eléctrico.
Por eso sigue siendo el lenguaje por defecto para lógica combinacional y enclavamientos de seguridad: arranque/parada de motores, condiciones de marcha, enclavamientos entre equipos, permisivos. Donde Ladder empieza a quedarse corto es en cálculos con decimales, gestión de arrays o algoritmos con múltiples condiciones anidadas, donde el diagrama se vuelve difícil de leer mucho antes que el equivalente en texto.
Function Block Diagram (FBD): programación por bloques
FBD representa el programa como una red de bloques funcionales interconectados por líneas de señal, de forma muy similar a como se dibuja un diagrama de instrumentación. Cada bloque encapsula una función (un temporizador, un PID, un escalado, un contador) y las señales fluyen de bloque en bloque sin necesidad de declarar variables intermedias explícitas para cada conexión.
Es el lenguaje natural para regulación continua y control de proceso: lazos PID de temperatura o presión, cascadas de control, procesamiento de señales analógicas de sensores. La representación gráfica hace evidente el flujo de la señal de un extremo a otro del lazo, algo que en Ladder resultaría forzado y en texto sería menos intuitivo de revisar en una pantalla de mantenimiento.
Sequential Function Chart (SFC): control de procesos por etapas
SFC no describe lógica combinacional sino secuencias: una serie de etapas (steps) conectadas por transiciones, donde cada etapa activa unas acciones y la transición a la siguiente depende de que se cumpla una condición. Es, en esencia, una máquina de estados dibujada.
Encaja de forma natural con procesos por lotes (dosificación, mezclado, procesos con receta), secuencias de arranque y parada de instalaciones complejas, y en general cualquier proceso que un operario describiría de forma natural como "primero esto, luego esto otro, y si pasa esto se salta a aquello". La ventaja frente a intentar programar lo mismo en Ladder es que el propio diagrama documenta la secuencia: ver en qué etapa está el proceso en un momento dado es tan simple como mirar qué paso está activo.
Structured Text (ST): el lenguaje textual de alto nivel
Structured Text es el lenguaje textual más potente de la norma, con una sintaxis heredada de Pascal: bucles FOR/WHILE, condicionales IF/CASE, operaciones matemáticas complejas y gestión de arrays y estructuras de datos. Es el lenguaje al que recurrir cuando la lógica es algorítmica más que eléctrica: cálculos de escalado no lineal, gestión de recetas con decenas de parámetros, comunicación con protocolos que requieren manipular buffers de bytes, o cualquier función reutilizable que conviene encapsular en un bloque de función bien probado.
En proyectos modernos sobre Codesys, ST ha ganado terreno de forma notable porque permite escribir librerías reutilizables, documentadas y testeables con la misma disciplina que el desarrollo de software convencional, algo que la programación puramente gráfica dificulta a partir de cierta complejidad.
Instruction List (IL): el lenguaje que la norma retiró
IL es un lenguaje textual de bajo nivel, muy próximo al ensamblador, que opera sobre un único registro acumulador. Fue habitual en generaciones anteriores de PLC por su eficiencia y su bajo consumo de memoria, pero la tercera edición de la norma IEC 61131-3 (2013) lo eliminó por su escasa legibilidad y mantenibilidad frente a ST. Hoy solo aparece en proyectos heredados que todavía no se han migrado, como los que describimos en nuestra guía de migración de S7-300 a S7-1500; para desarrollo nuevo no tiene sentido elegirlo.
Cómo elegir el lenguaje adecuado para cada tarea
La pregunta correcta no es "¿qué lenguaje uso para este proyecto?" sino "¿qué lenguaje uso para esta parte del proyecto?". Un programa de PLC bien estructurado mezcla lenguajes según la naturaleza de cada bloque funcional:
- Enclavamientos y seguridad → Ladder, por su legibilidad para mantenimiento eléctrico.
- Lazos de regulación y señales analógicas → FBD, por su correspondencia visual con el diagrama de control del proceso.
- Secuencias de arranque, parada y procesos por lotes → SFC, porque el propio diagrama documenta en qué etapa está el proceso.
- Cálculos, recetas, comunicaciones y librerías reutilizables → Structured Text, por su potencia y su capacidad de encapsular lógica compleja en bloques probados.
Esta combinación no es una excepción rara: es la práctica estándar en cualquier sistema de control de cierta envergadura, donde la mayoría de bloques de función de una librería bien diseñada suelen escribirse en ST, mientras que la orquestación general de la máquina se resuelve en SFC o Ladder según el caso.
El papel del entorno de programación en la elección
No todos los entornos soportan los cinco lenguajes con la misma profundidad. Codesys, al ser una implementación de referencia de la norma, ofrece los cinco lenguajes de forma nativa y permite mezclarlos libremente dentro de un mismo proyecto, incluyendo llamar un bloque de función escrito en ST desde un paso de un SFC. Entornos como TIA Portal de Siemens también implementan los cinco, aunque con matices propios en cada gama, como explicamos en nuestra comparativa Siemens vs Beckhoff. Conocer estas diferencias evita sorpresas al migrar un programa entre plataformas o al portar librerías de un proyecto a otro.
La programación asistida no cambia esta lógica, la acelera
Las herramientas de generación de código asistida están empezando a proponer bloques de función completos a partir de una descripción en lenguaje natural, como analizamos en nuestro artículo sobre inteligencia artificial en la programación de PLC. Lo que no cambia es el criterio de fondo: el código generado sigue teniendo que respetar qué lenguaje conviene a cada tipo de lógica, y sigue necesitando la revisión de un ingeniero que entienda por qué un enclavamiento va en Ladder y un cálculo de receta va en ST.
Cómo trabajamos los lenguajes PLC en Bluemation
En Bluemation no partimos de un lenguaje preferido, sino de la tarea que hay que resolver: definimos qué partes del programa van en Ladder, FBD, SFC o ST antes de escribir una sola línea, documentamos ese criterio y mantenemos librerías de bloques de función propias, probadas y reutilizables entre proyectos. Esa disciplina es la que permite que un programa siga siendo mantenible por otro ingeniero, o por el propio cliente, años después de la puesta en marcha.
Si tienes un proyecto de automatización y quieres una programación de PLC documentada, mantenible y con el lenguaje adecuado en cada parte del código, consulta nuestro servicio de programación de PLC o ponte en contacto con nosotros. Te contamos cómo abordaríamos tu proyecto sin compromiso.