Checklist de diagnóstico RS-485: cómo encontrar el fallo intermitente en tu bus Modbus RTU

Hace unos meses nos escribió un integrador a punto de perder a su mejor cliente. Su instalación —un PLC leyendo doce esclavos Modbus RTU por RS-485— funcionaba semanas enteras en el taller sin un solo error. En planta: timeouts, CRCs inválidos y tramas corruptas cada pocas horas, sin ningún patrón. Llevaba tres semanas reescribiendo el código. El código estaba bien.

El fallo estaba en la capa física: una topología en estrella, terminaciones donde no tocaba, un ramal con manguera sin trenzar compartiendo bandeja con la salida de un variador, y esclavos alimentados desde puntos distintos de la planta sin referencia común. Rehizo el bus en línea, con par trenzado apantallado, dos terminaciones de 120 Ω en los extremos reales y un tercer conductor de referencia. Cero errores desde entonces.

Esa historia (la contamos completa en la newsletter) tiene una moraleja incómoda: los problemas de RS485 casi nunca son de software, y casi siempre se diagnostican mirando el cable antes que el programa. Este artículo convierte aquella avería en lo que prometimos: la guía de diagnóstico paso a paso que usa nuestro equipo de soporte ante cualquier bus RS-485 inestable, y las reglas de diseño para que el tuyo no acabe en esa lista.

Por qué RS-485 falla "a veces": entender el enemigo

RS-485 (formalmente TIA/EIA-485) es una capa física diferencial: la información viaja en la diferencia de tensión entre los dos hilos (A/B o D+/D−), no entre un hilo y masa. Esa es su gran virtud —el ruido que se acopla por igual a ambos hilos se cancela— y también la fuente de todos los malentendidos:

• Es una línea de transmisión. A las velocidades y longitudes habituales en planta, el cable deja de ser "un cable" y pasa a ser una línea con impedancia característica (~120 Ω en cable trenzado típico). Cualquier discontinuidad de impedancia —una estrella, un ramal largo, una terminación ausente o duplicada— genera reflexiones que se superponen a la señal y corrompen bits.
• Diferencial no significa aislado. Los transceptores RS-485 estándar toleran un rango de tensión en modo común de −7 V a +12 V respecto a su propia masa. Si dos nodos del bus tienen masas a potenciales distintos (alimentaciones separadas, zonas distintas de la planta), ese margen se agota y el transceptor deja de leer correctamente, aunque la diferencia A−B sea perfecta.
• El fallo es proporcional al entorno, no al tiempo de prueba. Por eso el banco de pruebas engaña: tres metros de bus, una sola fuente, cero variadores. La planta multiplica longitud, ruido y diferencias de potencial. Lo que era margen sobrado se convierte en fallo intermitente.

Con esto en la cabeza, los fallos de comunicación de un bus rs485 se agrupan en cinco causas físicas: topología, terminación, polarización, referencia común/aislamiento y cable/apantallado. El checklist las recorre en orden de probabilidad y de facilidad de comprobación.

El checklist de diagnóstico, paso a paso

Antes de tocar nada: apunta los síntomas. ¿Fallan todos los esclavos o solo algunos? ¿Falla más el nodo más lejano? ¿Los errores coinciden con arranques de motores, maniobras o franjas horarias? Un patrón por leve que sea es media diagnosis.

Paso 1 — Dibuja la topología real (no la del plano)

Recorre el cable físicamente y dibuja cómo está tendido de verdad. Lo que buscas:

• RS-485 es una línea (daisy-chain): del maestro al esclavo 1, de este al 2, y así hasta el último. Sin ramales.
• Cada derivación (stub) es una antena de reflexiones. Regla práctica: derivaciones lo más cortas posible, idealmente < 30 cm; a 9.600–19.200 baudios hay algo más de margen, pero una estrella con ramales de decenas de metros es un fallo intermitente garantizado a cualquier velocidad.
• Si la instalación exige físicamente varios ramales largos, la solución no es cruzar los dedos: es un repetidor RS-485 por ramal, cada ramal terminado como bus independiente.

Si encuentras una estrella, ya tienes al sospechoso número uno. Sigue con el checklist igualmente: las averías de bus rara vez vienen solas.

Paso 2 — Verifica la terminación (el test de los 60 Ω)

El bus debe llevar dos resistencias de terminación de 120 Ω, una en cada extremo físico de la línea. Ni una, ni tres, ni dos en mitad del bus.

Comprobación en dos minutos: con el sistema apagado, mide con el polímetro la resistencia entre A y B en cualquier punto del bus.

Ojo con las terminaciones "invisibles": muchos equipos (PLCs, variadores, pasarelas) llevan la resistencia integrada y se activa por DIP switch o jumper. Inventaría cuáles la tienen activada. El clásico: se sustituye un variador de mitad de bus y el nuevo viene con la terminación activada de fábrica.

¿Cuándo se puede omitir la terminación? Solo en buses muy cortos (pocos metros) y a baja velocidad. En planta, termina siempre: el coste es cero y elimina toda una familia de fallos.

Paso 3 — Comprueba la polarización (fail-safe biasing)

Cuando ningún nodo transmite, el bus queda flotando y la diferencia A−B puede caer a cero: los receptores quedan en zona indefinida y cualquier ruido se interpreta como bits de arranque. Resultado típico: bytes basura entre tramas, errores de framing y esclavos que "responden a nadie".

La solución es la polarización del bus (bias): una resistencia de pull-up en una línea y una de pull-down en la otra —típicamente entre 450 Ω y 1 kΩ, en un solo punto del bus, normalmente el maestro— que garantizan más de 200 mV de diferencia en reposo.

Comprobación: con el sistema encendido y el bus en reposo (sin tráfico), mide la tensión DC entre A y B. Debe haber al menos 200–300 mV estables. Si mides prácticamente 0 V, el bus está sin polarizar. Igual que la terminación, muchos equipos llevan el bias conmutable: actívalo en un solo punto; polarización repartida por todo el bus carga los transmisores y distorsiona niveles.

Paso 4 — Referencia común y aislamiento: el fallo que "no tiene patrón"

Es la causa menos conocida y la que produce los síntomas más desesperantes, porque depende de qué motores estén arrancando en la otra punta de la planta.

• RS-485 es diferencial, pero el rango de modo común del transceptor es finito (−7 V a +12 V). Entre dos edificios, dos cuadros con fuentes distintas o dos tomas de tierra alejadas puede haber tranquilamente más diferencia que esa, y de forma variable.
• Solución de diseño: tercer conductor de referencia común entre todos los nodos (la tercera vena del cable, conectada al común de señal de cada transceptor). En buses largos, conviene hacerlo a través de una resistencia de ~100 Ω por nodo para limitar corrientes de bucle.
• Solución robusta para plantas grandes, buses entre edificios o entornos con variadores por todas partes: transceptores RS-485 con aislamiento galvánico. El aislamiento rompe el bucle de tierra por completo: cada nodo ve el bus, no la masa del vecino. Si el bus une zonas con alimentaciones independientes, el aislamiento no es un lujo: es la diferencia entre un bus estable y una avería crónica.

Comprobación orientativa: mide la tensión AC y DC entre la masa de señal de dos nodos alejados (con el bus desconectado de uno de ellos). Si ves varios voltios —o la lectura baila cuando arranca maquinaria— tienes un problema de modo común.

Paso 5 — Cable y apantallado: la parte que se decidió en el cajón

• Par trenzado siempre. El trenzado es lo que garantiza que el ruido se acople por igual a ambos hilos y se cancele. Manguera paralela de alimentación reutilizada como bus = antena.
• Impedancia característica ~120 Ω (cable específico para RS-485/Modbus o par trenzado apantallado equivalente). La terminación debe casar con el cable; terminar un cable de 100 Ω con 120 Ω ya introduce reflexión residual.
• Apantallado conectado a tierra en un extremo (el del cuadro principal) para evitar bucles por la malla; en instalaciones con buena red equipotencial puede conectarse en ambos extremos, pero solo si esa equipotencial existe de verdad. Una malla sin conectar no apantalla nada.
• Recorrido: bandeja separada de potencia; si hay que cruzar cables de motor, cruce a 90°. La salida de un variador es la fuente de ruido más agresiva del cuadro: distancia, y cable de motor apantallado por parte del variador (eso también es parte de tu bus, aunque no lo parezca).
• Longitud y velocidad: la regla clásica es 1.200 m a ≤100 kbps. A 9.600 baudios sobra margen; el problema casi nunca es la longitud total, sino todo lo anterior.

Paso 6 — Solo ahora, mira el software

Si la capa física ha pasado los cinco pasos y aún hay errores, toca la capa de protocolo:

• Silencio entre tramas: Modbus RTU exige 3,5 caracteres de silencio como separador. Maestros que encadenan peticiones demasiado rápido o conversores USB-RS485 con buffering agresivo lo violan.
• Timeouts coherentes con el esclavo más lento, reintentos con límite y contadores de errores por esclavo expuestos en diagnóstico. Un contador por nodo te dice en una tarde si el problema es de un tramo del bus o de un equipo concreto.
• Direcciones duplicadas y parámetros serie (velocidad, paridad, bits de stop) idénticos en todos los nodos: se comprueba en cinco minutos y aparece más veces de las que admitimos.

Y si tienes acceso a un osciloscopio, úsalo antes que ninguna herramienta software: la forma de onda diferencial en el nodo más lejano enseña reflexiones, niveles pobres y ruido acoplado de un vistazo. Flancos limpios y niveles francos = capa física sana.

Las reglas de oro para que el próximo bus no falle

1. El bus se diseña en un plano antes de cortar cable: topología en línea, ubicación de las 2 terminaciones, punto único de polarización, referencia común y recorrido.
2. Par trenzado apantallado de impedancia adecuada, malla a tierra con criterio.
3. Derivaciones cortas o repetidores; jamás estrellas.
4. Referencia común entre nodos siempre; aislamiento galvánico si el bus cruza zonas con alimentaciones distintas.
5. Documenta qué equipos tienen terminación y bias activados. Tu yo del futuro (o el técnico que sustituya un variador) te lo agradecerá.
6. En el programa: timeouts, reintentos limitados y contadores de error accesibles. El bus fallará alguna vez; la diferencia es si te enteras.

Los fallos intermitentes de comunicación casi nunca son de software. Si el error no se puede reproducir a voluntad, empieza por el cable: cinco de los seis pasos de esta guía se hacen con un polímetro y una mañana.

📥 Descarga la checklist: "De prototipo Arduino a instalación industrial"
El checklist completo de este artículo, junto con el resto de verificaciones de cableado, alimentación y comunicaciones que usamos en soporte, en un PDF imprimible para llevar al cuadro.
👉 Descarga la checklist gratuita →

¿Y el hardware? Los PLCs M-Duino traen Ethernet y RS-485 (Modbus) integrados de serie, con E/S aisladas y pensados para buses Modbus RTU con ruido real de planta. Detalle técnico y documentación descargable en la ficha de producto del M-Duino 21+.