Handshaking entre PLC y robot: Cómo estandarizar protocolos de interbloqueo

Para estandarizar el handshaking entre un PLC y un robot, los ingenieros deben definir intercambios booleanos deterministas para la disponibilidad, permisos de movimiento, restablecimiento de fallos y confirmación de posición. El objetivo es evitar el avance de la secuencia ante estados ambiguos o transitorios. En la práctica, los interbloqueos estandarizados reducen el riesgo de colisión al obligar al PLC y al controlador del robot a estar de acuerdo antes de que continúe el movimiento.

Un error común es pensar que el handshaking del robot consiste principalmente en mapear correctamente los bits. No es así. El problema más difícil es lograr que dos controladores coincidan en las transiciones de estado a pesar de los diferentes comportamientos de escaneo, tiempos de red y pérdida transitoria de retroalimentación. Un bit mapeado puede seguir siendo un bit erróneo.

En la revisión de Ampergon Vallis de 500 integraciones de celdas robóticas simuladas en OLLA Lab, el 68% de los fallos de colisión iniciales involucraron caídas asíncronas de la retroalimentación `In_Position` o de zona despejada (`zone-clear`) inferiores a 50 ms. Metodología: n=500 ejecuciones de validación de celdas de transferencia y pick-and-place simuladas, comparador de referencia = lógica de usuario de primera pasada antes de revisiones de antirrebote o endurecimiento de estado, ventana temporal = 1 de enero de 2026 al 15 de marzo de 2026. Esta métrica respalda un punto limitado: la inestabilidad de retroalimentación de corta duración es un modo de fallo frecuente en la primera pasada de la puesta en marcha simulada. No afirma una tasa de colisión a nivel industrial.

Un mal handshaking suele fallar de forma poco elegante. Una pinza se cierra antes de tiempo, un transportador indexa antes de que el robot se despeje, o una pinza entra en una zona que el PLC asumía vacía. La física rara vez se impresiona con una temporización optimista.

Las señales esenciales en un handshaking entre PLC y robot son la disponibilidad, los permisos de seguridad, la confirmación del estado de movimiento, la gestión de fallos y los bits de ejecución de secuencia. Si esas señales no están explícitamente definidas y enclavadas en un modelo de secuencia claro, el handshaking no está estandarizado; simplemente está conectado.

Señales principales de handshaking

Confirma que los requisitos previos del lado del PLC para el movimiento están satisfechos. Las condiciones típicas incluyen cadena de seguridad saludable, protecciones cerradas donde sea necesario, restablecimiento de parada de emergencia, ausencia de fallos activos en la celda y secuencia en un modo permitido.

• `PLC_System_Ready`

Confirma que el controlador del robot está disponible para participar en la operación automática. Esto puede incluir controlador saludable, ausencia de fallos de programa activos, ausencia de parada de protección y modo de operación alineado con la secuencia de la celda.

• `Robot_System_Ready`

Comando del PLC que solicita la habilitación de potencia de los servomotores o accionamientos, donde la arquitectura asigna esa autoridad al PLC.

• `PLC_Request_Motors_On`

Retroalimentación del robot que confirma que la potencia de accionamiento está realmente habilitada. El comando y la retroalimentación no son lo mismo. Las plantas vuelven a aprender esto en horarios inconvenientes.

• `Robot_Motors_On`

Una solicitud de restablecimiento deliberada emitida solo cuando las condiciones de restablecimiento son válidas.

• `PLC_Fault_Reset_Request`

Retroalimentación que muestra que el robot ya no está en estado de fallo.

• `Robot_Fault_Clear`

Indicación de posición completada o zona despejada utilizada para confirmar que un movimiento programado o una condición de despeje seguro ha ocurrido realmente.

• `Robot_In_Position`

Señal derivada o directa que confirma que el robot está fuera de una zona de interferencia protegida antes de que se mueva otro actuador.

• `Zone_Clear`

Disparador de secuencia emitido solo cuando todos los permisos requeridos y confirmaciones de estado son verdaderos.

• `PLC_Cycle_Start`

Retroalimentación de que el robot ha completado la tarea comandada o ha alcanzado el punto de control de secuencia esperado.

• `Robot_Cycle_Complete`

Definición operativa de un handshaking estandarizado

Un handshaking estandarizado entre PLC y robot es un intercambio bidireccional y determinista de estados booleanos con propiedad definida, transiciones válidas, comportamiento de tiempo de espera y respuesta ante fallos. La estandarización importa menos por elegancia que por repetibilidad: cada bit debe responder limpiamente a cuatro preguntas:

1. ¿Quién es el propietario?
2. ¿Cuándo puede activarse?
3. ¿Cuándo debe desactivarse?
4. ¿Qué hace la secuencia si nunca llega, llega tarde o parpadea?

Si faltan esas respuestas, la interfaz es optimismo sin documentar.

Contexto de las normas

Las normas y orientaciones relevantes incluyen:

• ISO 10218-1 / ISO 10218-2 para requisitos de seguridad de robots y sistemas robóticos.
• RIA TR R15.406 para prácticas de salvaguarda en celdas robóticas.
• IEC 61508 como marco más amplio de seguridad funcional para sistemas eléctricos/electrónicos/programables.

Estas normas no proporcionan una lista universal de bits para cada celda. Requieren un tratamiento disciplinado de las funciones de seguridad, modos de operación y reducción de riesgos.

Las condiciones de carrera causan colisiones cuando el PLC avanza la lógica de secuencia basándose en un estado transitorio o antiguo que el controlador del robot no ha mantenido de forma estable. El mecanismo habitual es simple: el PLC ve un permiso verdadero durante uno o dos escaneos, avanza una acción aguas abajo, y el robot ya se ha movido fuera del estado asumido o nunca lo alcanzó completamente.

Por qué la temporización del PLC y del robot discrepan

Un PLC y un controlador de robot no evalúan necesariamente el estado al mismo ritmo.

• Una tarea de PLC puede ejecutarse cada 2-10 ms.
• Las actualizaciones de E/S del robot pueden refrescarse en un intervalo diferente.
• El transporte de red añade fluctuación (jitter).
• La mezcla de movimientos (blending) puede invalidar brevemente un bit de posición.
• La lógica HMI o de supervisión puede escribir comandos de secuencia de forma asíncrona.

Esa discrepancia es suficiente para crear una falsa sensación de certeza. Los errores de secuencia suelen vivir en el espacio entre "verdadero una vez" y "verdadero el tiempo suficiente para confiar".

Patrones comunes de condiciones de carrera

#### 1. Pérdida transitoria de `In_Position` durante el movimiento mezclado

Un robot alcanza una región enseñada, establece `In_Position`, luego la pierde brevemente durante la mezcla de trayectorias o la transición de zona. El PLC ve el bit el tiempo suficiente para liberar una pinza, iniciar un indexador o abrir una puerta. El robot puede seguir estando físicamente dentro de la envolvente de interferencia.

#### 2. Confusión entre comando y retroalimentación

El PLC energiza un `Motors_On_Request` e inmediatamente trata al robot como capaz de moverse antes de recibir la retroalimentación verificada de `Robot_Motors_On`. Eso es lógica de estado de comando pretendiendo ser lógica de estado de equipo.

#### 3. Comportamiento de doble bobina o bit fantasma

El mismo estado de secuencia se escribe desde más de un peldaño, tarea o ruta de controlador. El resultado es un bit que parece válido en instantáneas de tendencias pero que no tiene una propiedad determinista.

#### 4. Sustitución de temporizadores por pruebas

Un programador inserta un retardo fijo en lugar de esperar una confirmación positiva como `Zone_Clear` o `Robot_In_Position_Stable`. Los temporizadores son útiles para el antirrebote y la supervisión de tiempos de espera. No son evidencia de que el movimiento se completó de forma segura.

Por qué la lógica estandarizada reduce este riesgo

La lógica estandarizada reduce las condiciones de carrera al obligar a que el avance de la secuencia dependa de un estado verificado, no de un tiempo transcurrido asumido. La distinción es compacta e importante: la temporización no es una prueba; la retroalimentación es la prueba.

Aquí es también donde se debe definir correctamente "listo para la simulación" (Simulation-Ready). Un ingeniero listo para la simulación no es alguien que puede dibujar sintaxis de escalera de memoria. Es alguien que puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento real del proceso antes de que llegue a una máquina real.

Para programar un interbloqueo seguro, utilice la verificación en serie de la disponibilidad, el estado libre de fallos y la retroalimentación estable antes de enclavar el siguiente comando de secuencia. El objetivo no es que el peldaño se vea ordenado. El objetivo es dificultar el movimiento prematuro.

### Ejemplo: Estructura de interbloqueo `PLC_Cycle_Start`

A continuación, un ejemplo de lógica de escalera en formato de texto que muestra un patrón acotado. El nombre de las etiquetas varía según la plataforma; el principio lógico no.

|----[XIC PLC_System_Ready]----[XIC Robot_Fault_Clear]----[XIC Robot_Motors_On]----[XIC Zone_Clear]----[TON T4:0 50ms]----| | | |----[XIC T4:0.DN]------------------------------------------------------------------------------------------------[OTE PLC_Cycle_Start]----|

Qué hace este peldaño

• `PLC_System_Ready` verifica que la celda tiene permiso para funcionar.
• `Robot_Fault_Clear` evita el avance de la secuencia hacia un estado anormal conocido.
• `Robot_Motors_On` confirma que el robot tiene realmente la potencia habilitada.
• `Zone_Clear` confirma que el robot está físicamente fuera del área de interferencia.
• El antirrebote `TON` requiere que la cadena de permisos permanezca verdadera durante un período estable mínimo antes de emitir `PLC_Cycle_Start`.

Por qué importa el temporizador de antirrebote

Un temporizador de antirrebote filtra la inestabilidad de la señal de corta duración causada por:

• fluctuación de red,
• transiciones de estado de movimiento,
• lógica de zona derivada ruidosa,
• vibración de sensores,
• caídas breves del estado del controlador durante las transiciones de programa.

Utilizado correctamente, un temporizador de antirrebote valida la estabilidad de la señal. Utilizado con pereza, un temporizador se convierte en una superstición con milisegundos adjuntos.

Reglas de programación recomendadas

#### Defina la propiedad explícitamente

Cada bit de handshaking debe tener una fuente autorizada. Si `Robot_In_Position` puede sintetizarse en tres lugares, no es una señal; es un argumento.

#### Separe los bits de comando de los bits de retroalimentación

No utilice `Request_Motors_On` como evidencia de que los motores están encendidos. Mantenga los comandos y las pruebas distintos.

#### Añada supervisión de tiempos de espera (timeout)

Cada retroalimentación esperada debe tener una ruta de tiempo de espera:

• comando emitido,
• retroalimentación esperada,
• tiempo de espera excedido,
• fallo enclavado,
• ruta de recuperación definida.

Una secuencia sin comportamiento de tiempo de espera no es robusta. Solo es paciente hasta que falla.

#### Enclave estados de secuencia, no esperanzas momentáneas

Utilice lógica de estado explícita o pasos de secuenciador para que la progresión dependa de transiciones validadas. Esto es especialmente importante cuando el movimiento del robot y los actuadores auxiliares comparten la misma envolvente de trabajo.

#### Diseñe la respuesta ante fallos antes de terminar la ruta feliz

Si `In_Position` cae a mitad del ciclo, defina si la celda:

• se pausa,
• se retrae,
• falla y requiere intervención del operador,
• o vuelve a un paso seguro conocido.

La máquina eventualmente hará esa pregunta. Es mejor responderla antes de la puesta en marcha.

OLLA Lab simula fallos de temporización asíncronos permitiendo a los ingenieros probar la lógica de escalera contra un gemelo digital mientras observan cambios de estado de E/S, comportamiento de secuencia y respuesta ante fallos en un entorno de riesgo contenido. Eso lo hace útil para el ensayo y la validación, no como sustituto de la aceptación formal en sitio o la certificación de seguridad.

Definición operativa de validación con gemelo digital en este contexto

En este artículo, validación con gemelo digital significa probar si la lógica de escalera produce el comportamiento de máquina previsto contra un modelo de equipo virtual realista bajo condiciones normales y anormales. Los comportamientos observables incluyen:

• alternar entradas discretas y verificar la respuesta de salida,
• monitorear transiciones de estado de etiquetas en secuencia,
• inyectar pérdida transitoria de retroalimentación,
• verificar si los interbloqueos bloquean movimientos inseguros,
• comparar el estado de la escalera con el estado del equipo simulado,
• revisar la lógica después de un fallo y volver a probar.

Cómo se ve el flujo de trabajo dentro de OLLA Lab

Usando OLLA Lab, un ingeniero puede:

• construir la lógica de handshaking en el editor de escalera basado en web,
• ejecutar el programa en modo de simulación,
• inspeccionar etiquetas, E/S y valores analógicos en el panel de variables,
• observar el comportamiento de la celda robótica o máquina en simulación 3D/WebXR,
• inyectar condiciones anormales como una señal de `Robot_In_Position` caída,
• confirmar si la secuencia se detiene, falla o se recupera según lo diseñado.

Aquí es donde OLLA Lab se vuelve operativamente útil. Da a los ingenieros un lugar para ensayar la clase exacta de errores que son demasiado costosos, demasiado inseguros o demasiado disruptivos para practicar en hardware real.

Un ejercicio de validación concreto

Una prueba de handshaking práctica en OLLA Lab podría verse así:

1. Construir una secuencia de pick-and-place con `PLC_System_Ready`, `Robot_Motors_On`, `Zone_Clear` y `PLC_Cycle_Start`.
2. Ejecutar la celda normalmente y confirmar que el robot despeja la zona antes de que el transportador indexe.
3. Inyectar una caída breve a mitad del ciclo en `Robot_In_Position` o `Zone_Clear`.
4. Observar si la lógica de antirrebote filtra el transitorio correctamente.
5. Aumentar la duración del fallo y verificar que el PLC detiene el avance de la secuencia y enclava un fallo.
6. Revisar la lógica del peldaño o del estado, luego volver a ejecutar la misma prueba.

Ese bucle —construir, observar, inyectar fallo, revisar, volver a probar— es el verdadero valor de entrenamiento. La sintaxis por sí sola no enseña el juicio de puesta en marcha.

Qué se debe y qué no se debe pedir a OLLA Lab que pruebe

OLLA Lab puede ayudar a los ingenieros a validar la lógica de secuencia, el comportamiento de E/S y el manejo de fallos antes del despliegue. Puede apoyar el ensayo de tareas de puesta en marcha como la verificación de interbloqueos y pruebas de estado anormal.

OLLA Lab no prueba por sí mismo:

• la corrección del cableado de campo,
• el rendimiento final de la función de seguridad,
• el logro de SIL,
• la firma de cumplimiento,
• o la competencia en el sitio bajo restricciones específicas de la planta.

Un simulador es un espacio de ensayo disciplinado. No es una exención de normas.

El handshaking entre PLC y robot debe guiarse por normas de seguridad formales, una filosofía de control documentada y un diseño de estado determinista. Las normas establecen el marco de seguridad; el diseño de la secuencia determina si la celda se comporta de forma coherente dentro de ese marco.

Normas y orientaciones para anclar el trabajo

Definen los requisitos de seguridad para robots industriales y sistemas robóticos, incluidas las responsabilidades de integración.

• ISO 10218-1 / ISO 10218-2

Proporciona orientación práctica sobre salvaguardas para aplicaciones robóticas y diseño de celdas.

• RIA TR R15.406

Enmarca la disciplina más amplia de la seguridad funcional para sistemas programables.

• IEC 61508

Definen la semántica de señales específica del controlador, bits de estado de movimiento y comportamiento de E/S de seguridad.

• Manuales de interfaz de robots del fabricante

Prácticas de ingeniería que importan más que los eslóganes

#### Escriba una matriz de interfaz

Documente cada bit de handshaking con:

• fuente,
• destino,
• estado normal,
• significado afirmado,
• comportamiento de restablecimiento,
• expectativa de tiempo de espera,
• consecuencia del fallo.

#### Defina el comportamiento "correcto" antes de probar

No comience la simulación o la validación tipo FAT sin una definición operativa de éxito. "El robot funciona" no es una definición. "El transportador indexa solo después de que `Zone_Clear` permanece verdadero durante 50 ms y no existe ningún fallo activo del robot" es una definición.

#### Trate los estados anormales como requisitos de primera clase

Pruebe:

• robot con fallo al inicio del ciclo,
• motores apagados durante la secuencia,
• `Cycle_Complete` antiguo,
• `In_Position` caído,
• restablecimiento intentado bajo condiciones inválidas.

#### Mantenga la seguridad y la lógica de secuencia distintas

Las funciones con clasificación de seguridad deben diseñarse y validarse de acuerdo con la arquitectura y las normas aplicables. Los bits de secuencia estándar no sustituyen a las funciones de seguridad. Mezclar esos roles descuidadamente es cómo la documentación se convierte en ficción.

Los ingenieros deben demostrar su habilidad en handshaking con un cuerpo compacto de evidencia de ingeniería que muestre la intención de la secuencia, el manejo de fallos y la disciplina de revisión. Una galería de capturas de pantalla no es suficiente. Cualquiera puede recolectar bits verdes.

Utilice esta estructura:

1) Descripción del sistema

Declare el propósito de la celda y las interfaces claramente.

Ejemplo: "Celda de transferencia de transportador de dos ejes con un robot articulado realizando pick-and-place entre la entrada y el nido de fijación. El PLC controla el transportador, la pinza y el estado de la secuencia. El robot proporciona retroalimentación de motores encendidos, fallo despejado, en posición y ciclo completado."

2) Definición operativa de "correcto"

Defina qué significa correcto en comportamiento observable.

Ejemplo: "`PLC_Cycle_Start` puede energizarse solo cuando los permisos de seguridad son saludables, los motores del robot están encendidos y `Zone_Clear` es verdadero continuamente durante 50 ms. El movimiento del transportador se inhibe mientras el robot está dentro de la zona de transferencia."

3) Lógica de escalera y estado del equipo simulado

Muestre la lógica del peldaño o del estado junto con la respuesta de la máquina simulada.

Incluya:

• fragmento de escalera,
• lista de etiquetas,
• matriz de secuencia,
• evidencia 3D o de estado de simulación que muestre al robot fuera de la zona cuando el transportador arranca.

4) El caso de fallo inyectado

Introduzca una condición anormal deliberadamente.

Ejemplo: "Caída inyectada de 30 ms en `Robot_In_Position` durante el movimiento de salida mezclado."

5) La revisión realizada

Explique el cambio de lógica y por qué fue necesario.

Ejemplo: "Se añadió antirrebote de 50 ms en `Zone_Clear`, se separaron las etiquetas de comando y retroalimentación, y se enclavó un estado de retención de secuencia ante el tiempo de espera."

6) Lecciones aprendidas

Declare la conclusión de ingeniería claramente.

Ejemplo: "La lógica inicial trataba la prueba de posición transitoria como un despeje estable. La lógica revisada requirió confirmación sostenida y evitó el movimiento prematuro del transportador."

Ese tipo de artefacto es útil porque demuestra razonamiento, no solo familiaridad con la herramienta.

Un handshaking estandarizado es mejor porque hace que el comportamiento sea predecible a través de celdas, equipos y condiciones de fallo. La lógica ad hoc puede funcionar durante una demostración y aun así fallar bajo deriva, latencia, ediciones de mantenimiento o escenarios de recuperación.

Beneficios prácticos de la estandarización

Todos saben qué significa cada bit y cuándo es válido.

• Reducción de la ambigüedad en la puesta en marcha

La propiedad clara y la lógica de tiempo de espera hacen que los fallos sean rastreables.

• Aislamiento de fallos más rápido

El movimiento depende de pruebas, no de suposiciones.

• Comportamiento de secuencia más seguro

Las plantillas estándar reducen la reinvención sin congelar el juicio de ingeniería.

• Mejor reutilización en proyectos

Un handshaking documentado es más fácil de probar sistemáticamente en un gemelo digital o entorno de simulación.

• Flujo de trabajo de simulación y FAT mejorado

El punto no es la pulcritud burocrática. El punto es que las interfaces repetidas fallan menos misteriosamente.

- Portal de especificaciones de OPC UA - Página de normas de robots y dispositivos robóticos ISO 10218 - Resumen de seguridad funcional IEC 61508 - Revisión de puesta en marcha virtual y gemelo digital (Journal of Manufacturing Systems) - Recursos del banco de pruebas de fabricación inteligente del NIST