¿Qué es el control de flujo serial?
El control de flujo serial es el mecanismo que permite a un receptor pedirle a un emisor que pause antes de que su buffer se desborde y se pierdan datos. Viene en una forma por hardware que usa líneas dedicadas de handshake y una forma por software que usa caracteres especiales embebidos en el flujo de datos. En la automatización de campo carga un segundo rol, fácilmente mal configurado: la línea RTS a menudo llavea un radio serial para transmitir, así que equivocarse con el control de flujo puede romper en silencio todo un enlace de radio a serial aun cuando todo lo demás esté correcto.
Control de flujo serial en una línea: El control de flujo serial regula el ritmo de los datos para que un emisor rápido no desborde el buffer de un receptor más lento, usando ya sea líneas de handshake por hardware como RTS y CTS o caracteres de software como XON y XOFF. En enlaces seriales conectados por radio, la línea RTS con frecuencia se reutiliza para llavear el transmisor del radio, lo que hace esencial su configuración correcta.
Control de flujo por hardware frente a por software
El control de flujo por hardware usa hilos adicionales junto a los de transmisión y recepción. En el esquema común RTS/CTS, un dispositivo afirma Request To Send y espera a que el otro extremo afirme Clear To Send antes de transmitir, y cualquiera de los dos lados puede desafirmar su línea para decir alto, lo que da pausa y reanudación casi instantáneas sin tocar los datos. El par DTR y DSR funciona de forma similar a nivel de disponibilidad de dispositivo. Como la señalización está fuera de banda, el control de flujo por hardware nunca corrompe la carga útil y responde rápido.
El control de flujo por software, llamado XON/XOFF, no necesita hilos adicionales. En cambio el receptor inyecta un carácter especial XOFF en el flujo de retorno para decir pausa y un carácter XON para decir reanudar, así que el ritmo viaja sobre las mismas dos líneas de datos. La contrapartida es que esos bytes de control no deben aparecer en los datos reales, lo que hace a XON/XOFF inadecuado para protocolos binarios como Modbus RTU, donde cualquier valor de byte es carga útil legítima. También reacciona más lento que las líneas de hardware porque el carácter de control espera en una cola.
Para la mayoría de los enlaces seriales industriales que llevan protocolos binarios, la respuesta práctica es deshabilitar el control de flujo por completo, o usar RTS/CTS por hardware solo donde el hardware genuinamente lo soporte. Encender el modo equivocado es una mala configuración frecuente: habilitar XON/XOFF en un enlace Modbus puede comerse en silencio bytes de carga útil que resulten iguales a los caracteres de control, y produce errores intermitentes y desconcertantes que son difíciles de rastrear hasta un ajuste de control de flujo.
Por qué el control de flujo evita los desbordamientos de buffer
Cada receptor serial tiene un buffer pequeño que retiene los bytes entrantes hasta que el software puede leerlos. Si los datos llegan más rápido de lo que se consumen, por ejemplo cuando la CPU está ocupada o el enlace aguas abajo es más lento, el buffer se llena y cualquier byte adicional se descarta, corrompiendo el mensaje. El control de flujo existe para aplicar contrapresión antes de que eso pase, y le dice al emisor que espere hasta que se libere espacio.
El desajuste que dispara el desbordamiento a menudo aparece en un punto puente en lugar de en un solo dispositivo. Un servidor de dispositivos seriales o un gateway de protocolo puede aceptar caracteres a una tasa en su puerto serial mientras los reenvía a una tasa distinta por la red, y sin control de flujo el lado más rápido termina inundando el buffer entre ellos. Un handshake por hardware bien cableado, o un protocolo que se autorregula, mantiene a los dos lados a la par.
En la práctica, muchos enlaces de campo robustos evitan el problema por diseño en lugar de depender del control de flujo. Modbus RTU, por ejemplo, envía mensajes cortos y acotados y espera una respuesta, así que un maestro bien portado nunca inunda a un esclavo más rápido de lo que este puede responder. Por eso el control de flujo se deja apagado con frecuencia en tales enlaces, con el propio ritmo de solicitud y espera del protocolo proveyendo el ritmo en su lugar.
Llaveo RTS y control de flujo en enlaces de radio SCADA
El giro más importante para la automatización de campo es que muchos radios seriales usan la línea RTS no para control de flujo sino como una tecla de transmisión push-to-talk. Cuando el dispositivo o gateway conectado afirma RTS, el radio se llavea y transmite; cuando RTS cae, el radio se desllavea y escucha. Esta reutilización implica que la temporización de RTS tiene que coincidir con los requisitos de llaveo del radio, y un dispositivo configurado para control de flujo RTS/CTS en lugar de llaveo RTS puede dejar el radio permanentemente desllaveado o mal temporizado, así que nada sale nunca al aire.
Esta es una fuente notoria de problemas al conectar por primera vez un dispositivo serial heredado a un radio. El enlace prueba bien en un cable de banco pero se queda en silencio por el radio porque la línea RTS está haciendo el trabajo equivocado, o porque no se consideró el retardo de llaveo y el radio trunca el inicio de cada mensaje. Diagnosticarlo requiere saber que los ajustes de control de flujo y el llaveo del radio comparten la misma línea física y pueden entrar en conflicto.
Para un gateway de SCADA de nube que sondea por radio serial, el arreglo es configurar el comportamiento de RTS para que coincida con el radio: afirmar RTS para llavear, permitir el retardo de llaveo especificado antes de enviar la carga útil, y bajar RTS para liberar el canal. Una vez que esa temporización es correcta, el gateway lee los dispositivos de campo y reenvía los datos a la nube como cualquier otro enlace. Una plataforma que reporta la salud de comunicación por dispositivo ayuda a confirmar que el llaveo es correcto, porque un RTS mal temporizado se manifiesta como timeouts consistentes que desaparecen en el momento en que el retardo se ajusta bien.
Preguntas frecuentes
¿Cuál es la diferencia entre control de flujo por hardware y por software?
El control de flujo por hardware usa hilos de handshake dedicados como RTS y CTS para señalizar pausa y reanudación fuera de banda, así que nunca perturba los datos y reacciona rápido. El control de flujo por software, XON/XOFF, envía caracteres especiales dentro del flujo de datos en su lugar, no necesita hilos adicionales pero arriesga corrupción en protocolos binarios donde esos caracteres pueden aparecer como datos reales. El de hardware se prefiere en general donde el cableado lo soporta.
¿Debo habilitar el control de flujo en un enlace Modbus RTU?
Por lo general no. Modbus RTU lleva datos binarios donde cualquier valor de byte es válido, así que el control de flujo por software XON/XOFF puede corromper mensajes, y el ritmo de solicitud y espera del protocolo ya regula el tráfico. La mayoría de los enlaces Modbus RTU corren con el control de flujo deshabilitado, reservando el RTS/CTS por hardware solo para casos especiales o, en radios, para llavear el transmisor.
¿Por qué importa la línea RTS en un radio serial?
Muchos radios seriales reutilizan la línea RTS como una tecla de transmisión en lugar de para control de flujo, así que afirmar RTS llavea el radio y bajarla libera el canal. Si un dispositivo está configurado para control de flujo RTS/CTS en lugar de llaveo RTS, o no se honra el retardo de llaveo, el radio puede no transmitir nunca o recortar el inicio de cada mensaje. Hacer coincidir el comportamiento de RTS con el radio es esencial para un enlace que funcione.
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.