¿Qué es una colisión de sondeo en un bus multipunto?
Un bus RS-485 multipunto comparte un par de cables entre muchos dispositivos, y eso funciona solo porque exactamente un dispositivo transmite a la vez. Cuando dos dispositivos hablan al mismo tiempo - porque comparten una dirección, porque un mensaje no solicitado cae a mitad de un sondeo, o porque los sondeos se superponen - sus señales colisionan en el cable y se corrompen entre sí. El resultado son errores CRC intermitentes y caídas que se ven exasperantemente aleatorias. Esta guía explica cómo ocurre una colisión de sondeo y cómo distinguir la contención del bus de un solo dispositivo muerto.
Colisión de sondeo multipunto en una línea: Una colisión de sondeo en un bus RS-485 multipunto ocurre cuando dos dispositivos transmiten a la vez sobre el par compartido, así que sus señales se superponen y se corrompen entre sí. Las causas usuales son dos dispositivos configurados con la misma dirección respondiendo al mismo sondeo, una respuesta no solicitada o retrasada que llega mientras otro dispositivo transmite, o sondeos superpuestos de un maestro mal temporizado. El síntoma son errores CRC o de trama intermitentes y caídas aparentemente aleatorias, en lugar de un dispositivo consistentemente callado.
Por qué un bus compartido solo puede tener un hablante
El RS-485 multipunto usa un solo par diferencial que cada dispositivo del segmento comparte, así que el medio es semidúplex: en cualquier instante, solo un transmisor puede estar manejando la línea mientras todos los demás escuchan. El protocolo impone esto con una estricta disciplina de turnos - el maestro direcciona a un dispositivo, ese dispositivo solo responde, y todos los demás permanecen en un estado receptor de alta impedancia. No hay arbitraje integrado que arbitre a dos dispositivos que ignoran el orden de turnos, a diferencia de las redes diseñadas para la contención. Todo el esquema descansa en la suposición de que exactamente un dispositivo transmite a la vez, y no tiene recuperación elegante cuando esa suposición se viola.
Cuando dos dispositivos manejan la línea a la vez, sus señales se superponen eléctricamente. El receptor ve una forma de onda que no es el mensaje de ninguno de los dos sino una mezcla corrupta, y la trama falla su suma de verificación o su chequeo de trama. Ninguno de los dos transmisores está funcionando mal en aislamiento; cada uno hace exactamente lo que se le dijo. La falla es emergente: existe solo porque dos de ellos actuaron simultáneamente sobre un medio que permite solo uno. Eso es lo que vuelve una colisión fundamentalmente distinta de una falla de dispositivo y por qué produce un síntoma disperso en lugar de uno limpio y repetible.
Las maneras en que dos dispositivos terminan hablando a la vez
La causa más común es una dirección duplicada. Si dos dispositivos del bus comparten el mismo ID de unidad o dirección de esclavo - un descuido de puesta en marcha, un dispositivo cambiado sin re-direccionar, o una dirección por defecto sin cambiar - entonces cada sondeo a esa dirección lo responden ambos, y sus respuestas colisionan. Esto es insidioso porque cada dispositivo individualmente está bien y hasta podría responder correctamente cuando el otro casualmente está callado, así que los errores van y vienen según el tiempo. Una segunda causa es el tráfico no solicitado: un dispositivo o protocolo que envía un reporte por excepción o una respuesta retrasada puede empezar a transmitir mientras el maestro está a mitad de una transacción con otro dispositivo, pisando la respuesta en curso.
El tiempo en los bordes de una transacción es un tercer contribuyente. Los transceptores RS-485 necesitan un momento para dar vuelta la línea entre recibir y transmitir, y si un dispositivo es lento en soltar el bus, o el maestro inicia el siguiente sondeo antes de que la respuesta anterior haya drenado por completo, la cola de un mensaje se superpone con la cabeza del siguiente. Un horario de sondeo demasiado agresivo para el tiempo de vuelta de los dispositivos, o un maestro que no espera lo suficiente por una respuesta antes de seguir, fabrica colisiones aun con direcciones únicas. En cada caso el hilo común es la superposición en el tiempo sobre un medio que no tolera ninguna, y la corrupción cae sobre la transacción que resultó estar en curso.
Detectar contención frente a un dispositivo muerto, en SCADA en la nube
La distinción diagnóstica clave es la consistencia. Un solo dispositivo muerto falla de forma limpia y repetible: nunca responde, así que su sondeo agota el tiempo de espera cada vez mientras todos los demás dispositivos del mismo bus siguen respondiendo perfectamente. Una colisión falla de forma inconsistente: los errores son intermitentes, pueden moverse entre dispositivos, y el dispositivo afectado responde a veces y se corrompe otras. Si ve errores CRC o de trama dispersos por el bus, o un dispositivo que responde de forma intermitente mientras sus vecinos también se ven ocasionalmente perturbados, la contención es mucho más probable que una falla de hardware. Una prueba reveladora es reducir el bus a un dispositivo a la vez: si cada uno funciona solo pero fallan juntos, el medio se está compartiendo mal, no está roto.
Una plataforma de SCADA en la nube vuelve visible este patrón mediante estadísticas de sondeo por dispositivo reunidas con el tiempo. Cuando la plataforma rastrea la tasa de éxito, el conteo de tiempos de espera y el conteo de errores CRC por dispositivo a través de un segmento, una colisión por dirección duplicada aparece como dos o más dispositivos con fallas correlacionadas e intermitentes en lugar de un dispositivo aplanado en cero. Esa firma - errores compartidos y dependientes del tiempo frente a un solo silencio consistente - es exactamente lo que separa una colisión de un nodo muerto, y tenerlo registrado en lugar de adivinado apunta al técnico hacia re-direccionar, ralentizar el horario de sondeo o cazar a un hablante no solicitado en lugar de cambiar un dispositivo sano. En una plataforma como Merobix que supervisa muchos buses seriales remotos, esa vista estadística es lo que convierte caídas de apariencia aleatoria en un problema de contención diagnosticable. Este modo de falla no lo cubren las páginas de RS-485, de ID de unidad Modbus ni de horario de sondeo, que describen los mecanismos en lugar de la colisión misma.
Preguntas frecuentes
¿Por qué los dispositivos de mi bus RS-485 caen de forma intermitente y aleatoria?
Las caídas aleatorias e intermitentes a través de un bus RS-485 compartido son una señal clásica de una colisión de sondeo - dos dispositivos transmitiendo a la vez y corrompiéndose entre sí, casi siempre porque dos comparten la misma dirección, o porque una respuesta no solicitada o un sondeo superpuesto pisa una transacción en curso. La aleatoriedad viene de que los errores dependen del tiempo, así que un dispositivo responde a veces y falla otras. Un solo dispositivo muerto, en cambio, falla de forma consistente en cada sondeo.
¿Cómo distingo una colisión del bus de un solo dispositivo fallido?
La consistencia es la pista. Un dispositivo muerto agota el tiempo de espera en cada sondeo mientras todos sus vecinos responden perfectamente; una colisión produce errores intermitentes que pueden moverse entre dispositivos y correlacionarse entre más de un nodo. Las estadísticas de CRC y tiempo de espera por dispositivo lo dejan claro, y reducir el bus a un dispositivo a la vez es una prueba fuerte: si cada uno funciona solo pero fallan juntos, tiene contención en un medio compartido, no un dispositivo roto.
¿Dos dispositivos con la misma dirección pueden causar problemas de comunicación?
Sí. Las direcciones duplicadas son la causa más común de colisiones multipunto. Cuando dos dispositivos comparten un ID de unidad o dirección de esclavo, ambos responden cada sondeo a esa dirección y sus respuestas colisionan en el cable, produciendo errores CRC o de trama. Como cada dispositivo está individualmente sano y solo colisiona cuando ambos casualmente transmiten juntos, las fallas son intermitentes y difíciles de fijar hasta que se busca el duplicado y se re-direcciona uno de ellos.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.