Comunicación PLC–robot: estados, señales y recuperación ante fallos

En breve: Una interfaz fiable entre PLC y robot es una máquina de estados acordada: toda petición recibe confirmación, todo trabajo termina en «completado» o en «fallo», toda espera tiene un tiempo límite y todo rearranque tiene condiciones explícitas. Un puñado de bits con tiempos ajustados a ojo funciona hasta la primera interrupción.

Por qué fallan los bits sueltos

Dos controladores que intercambian señales no comparten reloj ni ciclo de programa. El PLC y el controlador del robot leen entradas, ejecutan la lógica y escriben salidas cada uno a su ritmo, y el bus de campo que los une añade su propio intervalo de actualización. Una señal que un lado activa y desactiva deprisa puede no llegar a verla el otro; una señal que se deja activada puede leerse dos veces. En funcionamiento normal estos efectos son raros, y por eso una interfaz hecha con un bit de «inicio» y otro de «terminado» puede superar una demostración. El problema aparece tras una parada, un rearme o una pérdida de comunicación, cuando los dos controladores ya no coinciden sobre qué se pidió y qué se terminó.

Defina el contrato como estados

Describa el intercambio como estados con un propietario, no como una lista de variables. Una secuencia ilustrativa es reposo/listo, petición, aceptado, ocupado, completado y fallo. Estos nombres son ejemplos didácticos; no son una norma ni la lista de señales de ningún fabricante. Para cada transición, anote qué controlador la provoca, qué condición la hace válida, cuánto puede tardar el otro lado en responder y qué ocurre cuando ese tiempo se agota.

El patrón básico es un intercambio en cuatro pasos: el PLC activa la petición, el robot la confirma, el PLC retira la petición y el robot retira la confirmación. Mantener cada estado hasta recibir respuesta evita depender de captar un pulso breve. No elimina los requisitos temporales: define ciclos de comunicación, watchdogs, plazos de confirmación y la respuesta de cada parte si el intercambio deja de avanzar.

Evite las órdenes obsoletas y duplicadas

Una petición activa durante un rearme puede confundirse con una orden nueva al rearrancar. Exige una secuencia definida de vuelta al estado de reposo antes de aceptar otra. Devuelve el identificador de trabajo o receta para confirmar qué operación se solicita, pero no lo utilices como única identidad de la ejecución: varias piezas pueden compartir receta. Cuando la interfaz lo permita, añade un identificador de secuencia de mando y define su persistencia, desbordamiento y reglas de sesión o reinicio. Especifica cómo reconciliar duplicados y finalizaciones inciertas. Tras el rearranque, establece el estado real del equipo y de la pieza —pinza ocupada o vacía, útil cargado o no— antes de reanudar el automático. Los identificadores, por sí solos, no prueban que una operación física haya terminado exactamente una vez.

Separe la seguridad del control ordinario

Un bit de listo, una señal de vida (heartbeat) o un indicador llamado «seguro para entrar» que viaja por la interfaz estándar es un dato de control ordinario. No es una función de seguridad, se llame como se llame. Las paradas de protección, la protección de accesos y las demás funciones de seguridad se diseñan y se validan aparte, a partir de la evaluación de riesgos de la aplicación robótica completa, que es el objeto de la norma ISO 10218-2:2025. Aun así, el intercambio de señales debe comunicar los eventos de seguridad como información, para que el operario distinga un fallo de proceso de una parada de seguridad y elija la recuperación adecuada. La recuperación manual es un trabajo no rutinario, y OSHA señala que muchos accidentes con robots ocurren en condiciones de funcionamiento no rutinarias.

Ensaye los casos interrumpidos

Presencie algo más que el funcionamiento normal: peticiones en rápida sucesión, una interrupción de la comunicación, un apagado y encendido de cada controlador en mitad de un trabajo, la falta de la señal de confirmación de la pinza y una recuperación manual controlada. Registre los eventos con marca de tiempo en ambos controladores para poder reconstruir su orden. En cuanto al vocabulario, PackML (ISA-TR88.00.02), desarrollado por OMAC y adoptado por ISA, es un modelo publicado de estados de máquina. Describe estados de máquina, no señales de robot.

Lista de comprobación antes de comprometer presupuesto o alcance

• Una tabla de propiedad de las señales y un diagrama de transiciones de estado acordados por los dos programadores.
• Un tiempo límite y una reacción definida para cada espera.
• Una regla para las peticiones obsoletas y duplicadas, con un identificador de trabajo cuando sea útil.
• Un procedimiento de rearranque para cuando se haya reiniciado uno de los controladores, o los dos.
• Las funciones de seguridad evaluadas y validadas aparte del intercambio de señales.
• Un registro en la FAT de los casos interrumpidos, con las alarmas y las acciones del operario.

Lo que esta guía no establece

Esta guía es una ayuda para la planificación. No define ninguna lista normalizada de señales, no describe ningún robot ni PLC concreto y no recoge ensayos. El comportamiento de las salidas ante una parada, ante la pérdida del bus y en el rearranque varía de un producto a otro y debe tomarse de la documentación de los fabricantes. Nada de lo aquí expuesto sustituye la evaluación de riesgos ni la validación de las funciones de seguridad, que deben realizar sobre el sistema real personas debidamente cualificadas.

Fuentes y verificación adicional

• ISO — ISO 10218-2:2025, Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells (aplicaciones de robots industriales y células robotizadas; página del catálogo; 2025-02; consultado el 2026-10-11).
• OMAC — PackML: página general que describe PackML como desarrollado por OMAC y adoptado por ISA como TR88.00.02 (sin fecha; consultado el 2026-10-12).
• OSHA — Robotics: página general que indica que muchos accidentes con robots ocurren en condiciones de funcionamiento no rutinarias (sin fecha; consultado el 2026-10-12).

Siguiente paso útil

Si está especificando una interfaz entre PLC y robot, dibuje el diagrama de estados y la tabla de señales antes de escribir una sola línea de código, y consulte después la página de Robótica y Automatización. Los proyectos que parten de ahí se definen y se entregan a través de Eurobots/ReBots, y la evaluación empieza por la viabilidad y el reparto de responsabilidades, no por una instalación llave en mano dada por supuesta. La trayectoria de ingeniería que hay detrás de estas guías está en el portafolio de AYXWORKS.