Equivalencias entre marcas de PLC: conceptos y nombres

Respuesta corta

Las marcas de PLC comparten los mismos conceptos (entradas, salidas, temporizadores, bloques de función) con nombres, entornos y direccionamiento distintos. Conocer las equivalencias ayuda a leer un programa ajeno, planificar una migración y especificar sin depender de una sola marca. Un programa no se traslada sin trabajo de adaptación.

Respuesta corta

Un PLC de cualquier marca hace lo mismo: lee entradas, ejecuta un programa en ciclos y escribe salidas, como se describe en qué es un PLC y su ciclo de scan. Lo que cambia es el entorno de programación, el modelo de direccionamiento, los nombres de las instrucciones y la forma de configurar hardware y redes. La IEC 61131-3 acerca los lenguajes, pero no unifica el resto. Esta guía es un mapa de nombres y de criterios; las referencias exactas de cada modelo salen siempre de su manual. Las marcas se citan como ejemplos, sin recomendar ninguna.

Entornos de programación

Fabricante	Entorno típico	Observación general
Siemens	TIA Portal	Programación, hardware y HMI en un solo proyecto; texto estructurado conocido como SCL
Rockwell Automation (Allen-Bradley)	Studio 5000	Modelo basado en nombres (tags); ladder, texto, bloques y SFC
Mitsubishi Electric	GX Works	Direccionamiento por letras de dispositivo (X, Y, M, D)
Omron	Sysmac Studio	Entorno con variables con nombre y lenguajes de la IEC 61131-3
Schneider Electric	EcoStruxure Machine Expert y Control Expert	Según la familia de controlador
Fabricantes con base CODESYS	Entornos derivados de CODESYS	Estructura común entre marcas
OpenPLC	Editor de código abierto	Los cinco lenguajes; ver simulación y herramientas

Los nombres de productos cambian con el tiempo: verifique en el sitio del fabricante el entorno que corresponde a cada familia vigente.

Conceptos y sus nombres

Concepto	Notación habitual de la norma	Variantes frecuentes
Entrada digital	`%I0.0` o variable con nombre	`I0.0`, `X0`, nombre jerárquico módulo-canal
Salida digital	`%Q0.0`	`Q0.0`, `Y0`, nombre jerárquico
Marca de memoria	`%M`	`M`, bit de dato, etiqueta interna
Registro de datos	`%MW`, variable global	`DB` (bloque de datos), `D`, etiqueta de tipo entero
Temporizador de retardo a la conexión	`TON`	Bloque de la norma, o temporizador propio con base de tiempo y bit de terminado
Contador ascendente	`CTU`	Contador con valor preseleccionado y bit de terminado
Bloque de función propio	`FUNCTION_BLOCK`	FB, AOI, módulo de función
Función	`FUNCTION`	FC, función definida por el usuario
Tarea periódica	Tarea con intervalo	Organización de bloques de ciclo, tarea continua o periódica

La diferencia más visible es el modelo de memoria: en unas marcas el programador define variables con nombre sin pensar en la dirección; en otras, la dirección absoluta sigue siendo importante. Quien migra debe volver a trazar cada señal. Para el fundamento de tipos y direcciones, vea direccionamiento y tipos de datos.

Diferencias que más sorprenden al migrar

Temporizadores. Unos usan el bloque estándar con un valor de tipo tiempo. Otros usan un temporizador con base de tiempo y valor preseleccionado en unidades de esa base, con bits de estado propios. La lógica es igual; la escritura, no.
Estructura del programa. Algunas marcas organizan el proyecto en rutinas dentro de tareas; otras, en bloques de organización llamados por el sistema.
Contactos de flanco. Cada fabricante los implementa distinto; algunos exigen una variable de memoria auxiliar.
Arrays y estructuras. Los límites, la indexación (desde 0 o desde 1) y la forma de declararlos varían.
Retención. Qué se conserva tras un corte y cómo se configura.
Comunicaciones. Los bloques para Modbus, redes industriales o comunicación entre controladores son propios de cada marca.
Diagnóstico. Palabras de estado, códigos de falla y LED de módulo son particulares.
HMI. El panel y el controlador comparten o no un proyecto según el fabricante.

Ejemplo ilustrativo: el marcha-paro del motor de 15 kW en tres marcas

Datos supuestos: motor de 15 kW, 400 V. Tres entradas (paro, marcha, térmico) y una salida (contactor).

Señal	Marca A (notación de norma)	Marca B (letras de dispositivo)	Marca C (nombres)
Paro	`%I0.0`	`X0`	`Local:1:I.Data.0`
Marcha	`%I0.1`	`X1`	`Local:1:I.Data.1`
Térmico	`%I0.2`	`X2`	`Local:1:I.Data.2`
Contactor	`%Q0.0`	`Y0`	`Local:2:O.Data.0`

La lógica es idéntica en las tres: la salida se mantiene sola y se interrumpe con el paro o con el térmico. Lo que cambia es la nomenclatura. Estos tres formatos son ejemplos ilustrativos de las familias de notación, no direcciones de un equipo concreto. En el proyecto real, la dirección sale de la configuración de hardware.

Cómo evitar depender de una sola marca

Escribir la especificación del control con la lógica y no con las direcciones: tablas de señales, secuencias, enclavamientos.
Mantener la lógica en bloques de función genéricos por tipo de equipo.
Documentar la lista de señales en un formato propio del proyecto.
Usar protocolos abiertos para el enlace con SCADA y otros sistemas, como Modbus RTU y TCP.
Incluir en la contratación la entrega del código fuente y las herramientas de licencia necesarias.

Cómo conviene organizar un proyecto multimarca

En plantas con equipos de varios fabricantes, es frecuente tener más de una marca de controlador. Algunas prácticas que reducen el costo de mantener ese conjunto:

Una especificación funcional común para todos los equipos, escrita sin referencia a marcas.
Un estándar de señales hacia el SCADA, con nombres, unidades y estados iguales sin importar el controlador.
Bibliotecas equivalentes de bloques por tipo de equipo, con la misma interfaz lógica.
Respaldo centralizado de todos los proyectos, con registro de versiones y licencias.
Capacitación cruzada del personal de mantenimiento en los conceptos comunes.

El objetivo es que la planta se opere de la misma forma, aunque por dentro los controladores sean distintos.

Qué verificar al elegir un entorno

Más allá de los nombres, al comparar entornos, mire cuatro cosas:

Si el proyecto completo (controlador, periferia, redes y panel) vive en una sola herramienta.
Qué tan bien soporta bibliotecas propias.
Cómo gestiona el control de versiones y la comparación entre programas.
Qué licencias y actualizaciones requiere durante la vida de la planta. También pesa la disponibilidad local de soporte, repuestos y personal formado. Esas condiciones influyen más en el costo total que el precio de la CPU. Una planta que va a operar veinte años debería preguntarse quién podrá abrir ese proyecto dentro de diez.

Un criterio adicional es la política de ciclo de vida del fabricante: cuánto tiempo mantiene un modelo en catálogo, qué sucesor publica y cómo es el camino de migración. Esa información se consulta en el sitio del fabricante y se guarda en el expediente del proyecto.

Errores frecuentes

Suponer que «es lo mismo» y reutilizar tiempos y escalas sin revisar.
Migrar sin lista de señales, reconstruyéndola del programa antiguo.
Ignorar diferencias de ciclo de scan entre el controlador viejo y el nuevo.
Perder comentarios y nombres al convertir.
No probar de nuevo los casos de falla con el programa migrado.
Olvidar la configuración de comunicaciones (direcciones, velocidades, mapas).
Entregar el programa sin las licencias o los archivos de proyecto necesarios para mantenerlo.
Cambiar de marca solo por precio de hardware sin costear reentrenamiento, software y repuestos.

Lista de verificación

Lista de señales completa antes de migrar.
Lógica documentada por equipo, independiente de la marca.
Equivalencias de instrucciones revisadas una por una.
Tiempo de scan y tiempos de proceso comparados.
Comunicaciones y mapas de datos redefinidos y probados.
Pruebas completas, con fallas, sobre el programa nuevo.
Código fuente, licencias y respaldos entregados.
Personal de mantenimiento formado en el nuevo entorno.

Dudas técnicas frecuentes

¿Cuál es la marca más usada?: depende del país y de la industria; no hay una respuesta única.
¿Un controlador de una marca puede hablar con otro?: sí, por protocolos comunes; el programa interno sigue siendo propio.
¿Hay un formato de intercambio?: PLCopen define uno en XML que algunos entornos admiten parcialmente.
¿Cuánto cuesta migrar?: depende del tamaño y la documentación; se estima con la lista de señales y la complejidad de la lógica.

Cómo le ayudamos

Una migración o una ampliación bien planificada parte de la lista de señales, la lógica documentada y un plan de pruebas. En Tiza Group hacemos esa ingeniería y las pruebas, y luego ponemos el sistema en servicio. Vea diseño de ingeniería y estudios y pruebas y puesta en servicio, o escríbanos por contacto.

Guías relacionadas

Referencias

Documentación de los fabricantes citados como ejemplo: Siemens (formación SCE), Rockwell Automation (Literature Library), Mitsubishi Electric (FA e-Learning), Omron (manual de Sysmac Studio).
PLCopen, formato de intercambio XML.
IEC 61131-3 (norma de pago).

Preguntas frecuentes

¿Se puede convertir un programa de una marca a otra automáticamente?

Existen utilidades de conversión que cubren parte de la lógica, pero rara vez todo. Las instrucciones propias, la configuración de hardware, las comunicaciones y los bloques de sistema se rehacen. Todo programa convertido debe revisarse y probarse.

¿Qué es CODESYS y por qué aparece en varias marcas?

Es un entorno de programación según la IEC 61131-3 que numerosos fabricantes usan como base de sus propios controladores. Quien aprende CODESYS reconoce buena parte del entorno en equipos de marcas distintas.

¿Qué marca de PLC conviene aprender?

La que predomine en la industria o la región donde se vaya a trabajar. Los conceptos son los mismos, y quien domina la norma y la estructura de un proyecto pasa de una marca a otra con relativa facilidad.

¿Una norma uniformiza los entornos?

La IEC 61131-3 uniformiza los lenguajes y la estructura, pero cada fabricante conserva su hardware, su direccionamiento, sus instrucciones propias y su forma de configurar redes y periferia.