El bloqueo de muting que dejó un carro atrapado dentro de su propio campo de seguridad

Una barrera fotoeléctrica tiene exactamente un trabajo: parar la máquina cuando una persona está donde no debería. En una instalación de muting en la que trabajé, lo hizo a la perfección. Y al hacerlo, atrapó justo el carro que estaba construida para dejar pasar.

Esta es la versión larga de algo que publiqué, porque la versión corta no deja sitio para la parte que de verdad importa: el porqué ocurrió, y por qué el arreglo evidente resultó ser peor que el problema. Si usas muting en algún sitio, esta es una trampa que vale la pena entender antes de toparte con ella en una máquina en marcha, y no después.

Qué estábamos protegiendo

Un carro de transporte iba y venía a través de una zona protegida. La protección era una barrera fotoeléctrica SICK deTec4 con un controlador de muting DMM4 que inyectaba la señal de seguridad en un PLC de Siemens.

El problema de poner una barrera fotoeléctrica delante de un carro en movimiento es evidente: el carro corta los haces cada vez que pasa. Si la barrera tratara al carro como a una persona, la máquina dispararía en cada ciclo y nunca se movería nada. Así que necesitas que la barrera deje pasar el carro sin bajar la guardia frente a las personas.

Para eso sirve el muting.

Por qué existe el muting

El muting es la suspensión deliberada, automática y temporal de una función de seguridad para que un objeto previsto pueda atravesar un dispositivo de protección sin parar la máquina, mientras que una persona sigue sin poder hacerlo. No es un apaño ni una trampa. Es una función definida con sus propias normas detrás: la barrera fotoeléctrica en sí entra dentro de la IEC 61496 (equipos de protección electrosensibles), y la aplicación del muting en concreto la cubre la IEC 62046 (aplicación de equipos de protección para detectar la presencia de personas). El nivel de prestaciones que tiene que alcanzar el conjunto de la función de seguridad vive en la ISO 13849.

El truco del muting está en distinguir un carro de una persona. Eso se consigue con sensores de muting: sensores aparte, dispuestos de modo que solo el objeto previsto, llegando de la forma prevista, pueda satisfacerlos. Consigue el patrón correcto en el orden correcto y el controlador dice ese es el carro, y aplica el muting. Una persona que se acerca andando no puede reproducir ese patrón, así que para ella la barrera sigue activa.

En esta instalación era muting parcial: se silenciaban los haces inferiores para que el carro pudiera rodar por debajo, mientras los haces superiores seguían activos todo el tiempo para proteger a cualquiera que estuviera de pie en la zona. El muting en sí lo disparaban dos fotocélulas montadas en una pletina —una configuración L-muting— que se activaban a medida que entraba el carro.

Funcionó bien durante muchísimo tiempo. Hasta que dejó de hacerlo.

El bloqueo

Alguien cortó los haces superiores activos mientras el carro seguía parado dentro del campo.

Eso no es un fallo: es la barrera funcionando. Los haces superiores están ahí precisamente para esto. Las salidas OSSD (las salidas de seguridad que les dicen a los accionamientos «tenéis permiso para moveros») se dispararon. Comportamiento completamente correcto.

Aquí es donde se hace un nudo:

• El DMM4 suelta el muting en el instante en que dispara. Bien por sí solo.
• Pero el carro sigue ahí, todavía bloqueando los haces inferiores.
• Así que, sin muting, la barrera ahora ve también el carro como una obstrucción. Todo el campo se lee como bloqueado. Rojo total.
• No acepta un reset, porque un reset quiere ver primero todo el campo despejado: la barrera tiene que estar mostrando amarillo parpadeante antes de aceptar un reconocimiento.

Ahora sigue el bucle. El carro no puede moverse, porque los accionamientos necesitan el OK de seguridad para funcionar. La seguridad no puede reconocerse, porque la barrera no está despejada. Y la barrera no puede despejarse, porque el carro está aparcado en mitad de ella y no puede moverse.

Un bloqueo en toda regla. El carro físicamente atascado entre el emisor y el receptor, y ningún botón en el armario que lo sacara de ahí.

Flanco, no nivel

Esto me llevó un rato entenderlo de verdad, en lugar de resolverlo a la fuerza bruta.

El L-muting del DMM4 está disparado por flanco, no por nivel. Esa distinción es toda la historia, así que vale la pena ser preciso con ella:

• La lógica disparada por nivel actúa sobre un estado. Mientras la entrada esté en alto, la condición se mantiene. Le importa dónde está la señal.
• La lógica disparada por flanco actúa sobre una transición. Se dispara con el cambio: un flanco ascendente (0 → 1) o un flanco descendente (1 → 0). Le importa el momento en que la señal se mueve.

El DMM4 arma el muting con un flanco ascendente de los sensores de muting: el momento en que pasan de «no hay carro» a «llega el carro». Eso normalmente es exactamente lo que quieres: demuestra una aproximación reciente y secuenciada, en lugar de algo que simplemente está parado dentro del haz.

Pero recorre nuestra situación con eso en mente. La OSSD dispara. El carro no se va nunca. Así que los sensores de muting ya están en alto: se pusieron en alto cuando llegó el carro y se han quedado en alto todo el tiempo. Para que el muting se vuelva a armar, el DMM4 necesita ver un flanco ascendente. Y no hay ningún flanco ascendente disponible, porque la señal ya está arriba del todo. No puede subir desde un nivel en el que ya está. Sin flanco, no hay muting, y no hay salida.

Lo demostré de la forma más burda: saqué el carro del campo a mano y luego lo volví a meter. Aproximación nueva, flanco ascendente nuevo en los sensores de muting, y el muting volvió de inmediato. Eso lo confirmó. El sistema no estaba roto. Estaba haciendo exactamente lo que hace la lógica disparada por flanco. Simplemente no tenía ningún camino de vuelta a un estado de muting sin una transición que el propio bloqueo hacía imposible.

El arreglo de un botón, y el agujero que abrió

El arreglo evidente parecía limpio. En SICK Safety Designer, convertir la entrada de reset existente en una entrada de reset/override: un solo botón, y el DMM4 decide cuál de los dos es según el estado actual. Hacer override de la condición atascada, poner el carro en marcha, listo. Limpio sobre el papel.

Luego miré lo que hace en realidad el override y dejó de gustarme rápido.

Un override mantiene la OSSD en verde mientras el sensor de muting siga bloqueado. Solo suelta el override cuando el sensor pasa de 1 → 0, un flanco descendente, el carro saliendo por fin. Lo cual está bien si lo único que llega a bloquear ese sensor es un carro de verdad de camino a la salida.

Pero no hay nada que obligue a eso. Pon cualquier cosa delante del sensor de muting y el override mantiene la OSSD en verde básicamente para siempre. Toda la barrera —incluidos los haces superiores, los que protegen a las personas— puenteada, de forma indefinida, con un sensor bloqueado y una pulsación de botón.

Y fíjate en la simetría, porque aquí está la verdadera lección enterrada. El bloqueo original venía de una lógica disparada por flanco: necesitaba una transición que no estaba disponible. El arreglo con override está disparado por nivel: se mantiene activo mientras el estado se sostenga. Había cambiado un modo de fallo por otro. El primero te atrapa y lo ves. El segundo puentea tu protección y no lo ves. Es un cambio estrictamente peor.

Por qué el override es el arreglo equivocado

Incluso llamé a SICK para comentarlo, y nunca encontré una respuesta que me convenciera: ninguna que cerrara el agujero sin reintroducir alguna versión del problema original.

Por eso el override de un botón es el cambio equivocado. Un paro visible que necesita que alguien despeje físicamente el campo es molesto. Un puenteo silencioso y mantenible de una protección que cuida a las personas es algo de una categoría completamente distinta: no es algo que merezca la pena diseñar de forma intencionada para ahorrar unos segundos de recuperación.

Lo que me enseñó sobre el diseño de muting

Voy a ser honesto: nunca encontré un arreglo que me convenciera de verdad, y sigo creyendo que ahí fuera hay una respuesta más limpia a la que no llegué. Puesto a elegir, me quedo siempre con un paro visible y recuperable antes que con un puenteo que se puede mantener abierto.

Pero salí de aquello entendiendo el muting de una forma que ninguna hoja de datos me había enseñado. El muting es un agujero deliberado en tu función de seguridad. Eso no es una crítica: es su razón de ser, y es algo legítimo y normalizado. La disciplina está en mantener ese agujero estrechamente acotado: acotado por la lógica de los sensores, por la secuencia, por la geometría, por el tiempo, de modo que no se pueda forzar para abrirlo ni se pueda mantener abierto. Cada «comodidad» que le añades para recuperarte de un caso límite incómodo es candidata a ensanchar ese agujero, y el override era un ejemplo perfecto: resolvía una molestia real eliminando discretamente el límite.

Y lo que le diría a cualquiera que monte muting por primera vez: flanco frente a nivel no es una nota a pie de página. Es el comportamiento real de tu función de seguridad bajo las condiciones que no planificaste. La lógica disparada por flanco puede dejarte tirado cuando la transición que esperas no puede ocurrir. La lógica disparada por nivel puede mantener abierto un estado peligroso mientras algo lo sostenga en alto. Ambas son correctas. Ambas te morderán. Saber cuál de las dos has construido, y exactamente qué le pasa cuando la máquina acaba en algún sitio que no te imaginabas, es la mayor parte del trabajo.

El carro salió. Nunca di con el arreglo elegante que buscaba, pero ahora me fío mucho más del muting precisamente porque sé exactamente dónde están sus bordes.