Cómo corregir un error de timeout de Modbus

Síntoma y el orden para diagnosticar

El síntoma es inequívoco: el maestro registra un timeout, marca el tag como de calidad mala y reporta el esclavo como sin responder, normalmente en cada petición y no de forma intermitente. Como un timeout significa que el intercambio no se completó en absoluto, la división mental útil es accesibilidad frente a temporización. O la petición no llega al dispositivo correcto que escucha y responde, o sí llega pero la respuesta llega demasiado tarde para la paciencia del maestro. Casi todo timeout se resuelve en uno de esos dos cubos, y trabajarlos en orden evita perseguir el equivocado.

Empiece por el ID de unidad o esclavo equivocado, que es la causa más común. Cada petición Modbus lleva un ID de unidad, y el dispositivo solo responde peticiones que llevan su propia dirección, así que un driver apuntado a la unidad 1 cuando el dispositivo está en la unidad 3 hará timeout en cada sondeo aunque el cableado sea perfecto. Confirme la dirección configurada del dispositivo desde su propia pantalla o manual, no desde una suposición, y haga coincidir el driver con ella. En Modbus TCP el ID de unidad sigue importando aunque la IP identifique la caja, porque un gateway lo usa para elegir el dispositivo serial aguas abajo.

Si el direccionamiento está bien, pase a la accesibilidad. Confirme que el dispositivo esté de verdad energizado y, para TCP, que tenga la dirección IP correcta y que pueda alcanzarlo, por ejemplo con un ping y confirmando que el puerto TCP 502 esté abierto y no bloqueado por un firewall o por un límite de conexiones ocupado en el dispositivo. Para serial, confirme que el bus físico esté íntegro, que el maestro y el esclavo compartan la misma velocidad en baudios, paridad, bits de datos y bits de parada, y que ninguna falla de cableado o par invertido esté deteniendo la respuesta. Un dispositivo apagado, en la IP equivocada o detrás de un 502 bloqueado hará timeout de forma idéntica a un ID de unidad equivocado, por eso usted separa estas revisiones.

Ajuste de tiempos de sondeo que la mayoría de las guías omite

Una vez que ha probado que el dispositivo está bien direccionado y es accesible, un timeout terco suele significar que la temporización está mal en vez del destino. El tiempo de espera de respuesta del maestro es la ventana que espera una respuesta antes de declarar la falla, y si esa ventana está configurada más corta de lo que el dispositivo realmente necesita para dar la vuelta a una petición, el maestro se rinde mientras la respuesta aún va en camino. Los dispositivos lentos, los convertidores seriales baratos y en especial los enlaces que cruzan un salto de radio o celular pueden tardar mucho más en responder que un dispositivo Ethernet local, y un tiempo de espera por defecto afinado para una red local rápida es simplemente demasiado impaciente para ellos.

Ajuste el tiempo de espera al tiempo de vuelta real. Alargue el tiempo de espera de respuesta del maestro en pasos y observe si los sondeos empiezan a tener éxito; si una ventana más larga lo corrige, el dispositivo respondía todo el tiempo y el maestro se rendía temprano. En enlaces seriales y de radio, recuerde que la respuesta tiene que transmitirse a la velocidad en baudios del bus, así que una lectura grande de registros a una velocidad baja en baudios genuinamente toma tiempo, y el tiempo de espera debe cubrir la petición, el procesamiento del dispositivo, la vuelta de dirección y la respuesta completa. También ayuda espaciar los sondeos y reducir cuántos registros pide a la vez, ya que inundar un dispositivo lento o una radio compartida con peticiones rápidas puede empujar las respuestas más allá de la ventana aunque un solo sondeo hubiera tenido éxito.

Un gateway agrega una trampa más de temporización y mapeo. Un gateway Modbus TCP a RTU recibe la petición TCP, la reenvía al dispositivo serial, espera la respuesta serial y la pasa de vuelta, así que el tiempo de espera del maestro debe cubrir todo ese viaje de ida y vuelta más el lento tramo serial, no solo el rápido tramo TCP. Igual de importante, el gateway usa el ID de unidad para decidir a qué dispositivo aguas abajo reenviar, de modo que si el gateway no está configurado para remapear o enrutar el ID de unidad que usted usa, fallará en silencio al alcanzar el dispositivo y el maestro hará timeout. Cuando un dispositivo sondea bien conectado directo pero hace timeout a través de un gateway, sospeche primero del remapeo de ID de unidad del gateway y de su propio tiempo de espera de reenvío.

Timeouts en un contexto de SCADA y monitoreo remoto

En un sistema SCADA en vivo un timeout de Modbus rara vez llega solo, y la forma en que el maestro lo maneja importa tanto como la causa raíz. Un driver bien configurado reintenta una petición fallida unas cuantas veces antes de marcar el tag como malo, de modo que timeouts sueltos ocasionales en un enlace marginal pueden recuperarse sin que un operador lo note, mientras que un dispositivo verdaderamente ausente se queda malo tras agotar los reintentos. Configurar los conteos de reintentos y el tiempo de espera de respuesta juntos es el oficio práctico aquí: un tiempo de espera demasiado corto en un enlace lento convierte sondeos sanos en una tormenta de reintentos, mientras que uno demasiado largo en un dispositivo genuinamente muerto retrasa el momento en que el operador se entera de que algo anda mal.

Los sitios remotos hacen la disciplina de temporización aun más importante, porque la petición a menudo tiene que cruzar un enlace celular o de radio con latencia real antes siquiera de llegar al dispositivo de campo. Una plataforma SCADA en la nube como Merobix que sondea una RTU remota tiene que dar margen a ese viaje de ida y vuelta en su tiempo de espera de respuesta, y un valor afinado para una prueba de banco cableada hará timeout constantemente una vez que el mismo dispositivo esté detrás de un módem celular. Cuando un dispositivo que funcionó en el banco hace timeout en campo, la latencia del enlace, no el dispositivo, suele ser el cambio, y alargar el tiempo de espera para igualar la trayectoria real restaura el sondeo.

Por último, un timeout es una señal que vale la pena hacer visible en vez de esconder. Como normalmente significa que el dispositivo es inaccesible, un timeout persistente en un activo remoto es a menudo la primera indicación de que un sitio perdió energía, perdió su enlace de comunicaciones o tuvo una falla de dispositivo. Tratar la falla de comunicación por timeouts repetidos como un evento alarmable, distinto de una lectura de proceso mala, permite a los operadores responder pronto a un sitio muerto, y combinar eso con el ajuste de reintentos y tiempos de espera de arriba mantiene visibles las fallas genuinas sin ahogar al personal en alertas molestas de un enlace que apenas está lento.

Preguntas frecuentes