Datos serie ilegibles en el puerto COM: 7 comprobaciones

Cuatro valores deben coincidir: velocidad en baudios, bits de datos, paridad y bits de parada. Manda el manual del dispositivo. Si se perdió, 9600 8N1 es el ajuste de fábrica habitual, seguido de 19200 y 115200; algunos medidores y PLC salen de fábrica con paridad par, y un dispositivo a 8E1 leído a 8N1 produce exactamente el patrón de «un carácter erróneo cada pocas palabras».

La trampa es el diálogo de configuración de su propio programa. Lo que muestra no siempre es lo que envía: una aplicación puede cambiar cualquiera de los cuatro valores después de abrir el puerto, y un perfil equivocado, un valor predeterminado al que recurre o el valor por defecto de un controlador pueden anular el diálogo. Dos formas de ver la verdad:

• Observe la aplicación en modo Spy con los eventos del sistema activados. Las primeras líneas de la captura son la petición de apertura y la velocidad, bits de datos, paridad y bits de parada que la aplicación pidió realmente. La página del sniffer de puerto serie (en inglés) muestra dónde activarlo.
• Hable usted mismo con el dispositivo en modo Manual. Los cuatro valores pueden cambiarse con el puerto abierto, así que puede recorrer las velocidades estándar mientras el dispositivo sigue enviando y detenerse en la que el texto se vuelve legible. Para un dispositivo MODBUS de velocidad desconocida, el complemento de escaneo de dispositivos recorre las velocidades estándar por usted.

La basura que no cambia al apagar el dispositivo no viene del dispositivo. Los adaptadores USB cambian de número COM tras un reinicio o una actualización del controlador, dos adaptadores parecen iguales en una lista que solo muestra números, y en muchos PC el COM1 pertenece al motor de administración de la placa base y no a un conector. Abra la lista de puertos en Advanced Serial Port Monitor: muestra cada puerto con el nombre de su dispositivo, por ejemplo «COM7 - USB Serial Port (FTDI)», de modo que el adaptador y el número casan de un vistazo. Encontrar el puerto COM que usa una aplicación explica las otras maneras. Si el puerto se abre pero no llega nada en absoluto, es otro fallo; vea el puerto COM no funciona.

El control de flujo no revuelve bytes; los quita. El control de flujo por hardware (RTS/CTS) con un cable que no lleva esas líneas hace que el PC o el dispositivo esperen una señal que nunca llega, así que los datos llegan a ráfagas con huecos, o no llegan. El control de flujo por software (XON/XOFF) es peor con protocolos binarios: los bytes 0x11 y 0x13 se tragan como caracteres de control, la trama binaria llega uno o dos bytes corta y su suma de comprobación falla. Ponga primero el control de flujo en None y añada después solo lo que exija el manual del dispositivo. El monitor muestra el estado de las líneas de control y permite conmutar RTS y DTR a mano, lo que aclara si el dispositivo está esperando una línea.

Cuando la configuración es correcta y los datos siguen mal, el fallo está en el cable, y ningún ajuste de software lo arregla. Compruebe en este orden:

• RS232: cruzado o directo. De PC a dispositivo suele hacer falta un cable directo; dos ordenadores, o dos dispositivos que actúan ambos como terminal, necesitan un cable de módem nulo con TX y RX cruzados. El cable equivocado da silencio o ecos más que basura, pero un cable con hilos sin conectar puede dar ambas cosas. El pin 5 (masa de señal) debe estar conectado; sin él, el receptor no tiene referencia y lee ruido. Vea pines y señales RS232.
• RS485: A y B, terminación y masa. Con las líneas A y B intercambiadas la señal se invierte. Las líneas largas necesitan un terminador de 120 ohmios en cada extremo, no en medio. La falta de una masa común entre el conversor y el dispositivo es la causa clásica de errores que van y vienen con el tiempo atmosférico o con el arranque de un motor; tienda un tercer hilo para la masa aunque el bus «funcione» sin él.
• Un dispositivo cada vez. Quite del bus todos los dispositivos menos uno. Dos esclavos con la misma dirección responden a la vez y se corrompen mutuamente las tramas, y un transmisor averiado bloquea todo el bus. Si el dispositivo solo se lee limpio, vuelva a añadir los demás de uno en uno.
• Longitud y ruido. RS232 está especificado para unos 15 metros; más allá, baje la velocidad o pase a RS485. Mantenga los cables serie lejos de los cables de red eléctrica y de los variadores de frecuencia, y use cable apantallado con la pantalla puesta a tierra en un extremo.

La página de software RS485 (en inglés) muestra el cableado de un PC en un bus de dos hilos y cómo escuchar un bus que ya está en marcha.

La mayoría de los PC llegan a un dispositivo serie a través de un adaptador USB a serie o un conversor USB a RS485, y el adaptador es la pieza que más a menudo falla cuando los datos van limpios un rato y luego se rompen. Qué hacer:

• Cámbielo. La prueba más rápida de todas. Si un segundo adaptador con otro chip lee limpio el mismo dispositivo, ya encontró el fallo. Los adaptadores con chips FTDI, Silicon Labs CP210x o WCH CH340 y el controlador de su fabricante son la opción fiable; el controlador actual de Prolific rechaza los chips PL2303 falsificados, por eso un adaptador que funcionaba en un PC antiguo se para en uno nuevo.
• Impida que Windows lo apague. En el Administrador de dispositivos, abra el concentrador USB del adaptador y el puerto, y en la pestaña «Administración de energía» desmarque «Permitir que el equipo apague este dispositivo para ahorrar energía». Un dispositivo que se calla tras una pausa y vuelve al reconectar suele ser esto.
• Evite concentradores y cables USB largos. Conecte el adaptador directamente al PC. Los concentradores sin alimentación y los alargadores finos hacen caer la tensión y reinician el adaptador bajo carga.
• Compruebe el controlador. Una marca amarilla en el Administrador de dispositivos, o un puerto que aparece y desaparece, necesita el paquete de controladores del fabricante en lugar del genérico. Los adaptadores USB a serie no funcionan tras una actualización de Windows cubre la parte del controlador.
• Póngalo a prueba. Si el fallo solo aparece con tráfico sostenido, haga pasar el puerto por la prueba de estrés de puerto COM y vea a qué velocidad empiezan los errores.

Parte de la basura no es basura. Cambie el monitor a la vista HEX. Si los bytes se repiten con un patrón, empiezan por la misma cabecera o forman tramas MODBUS válidas con CRC correcto, los datos son binarios y lo único incorrecto era leerlos como texto. Si el texto es legible pero la disposición es rara, el problema es el fin de línea: los dispositivos envían CR, LF o CR LF, y un visor que espera lo contrario junta las líneas o las duplica. La vista ASCII muestra los caracteres de control, y el menú contextual envía CR, LF o ambos, para probar qué quiere recibir el dispositivo. Dos casos más: un dispositivo que usa 7 bits de datos muestra cada byte por encima de 127 como un carácter erróneo, y el texto no inglés necesita la página de códigos del dispositivo para mostrarse bien.

Las tramas que llegan partidas en dos, o sin los primeros bytes, son un fallo de temporización, no de datos. Las causas habituales:

• Conmutación de dirección en RS485. Un conversor semidúplex debe apagar su transmisor antes de que empiece la respuesta. Un conversor que necesita que el PC haga la conmutación recorta los primeros bytes de cada respuesta salvo que el programa active RTS en el momento justo; Advanced Serial Port Monitor tiene un modo RS485 precisamente para esos conversores. Los conversores con control automático de dirección evitan el problema.
• Silencio entre tramas. MODBUS RTU necesita una pausa de 3,5 tiempos de carácter entre tramas. Un maestro que envía la siguiente petición antes de que termine la respuesta, o un esclavo que responde demasiado rápido para el conversor, fusiona tramas.
• Búfer del adaptador. Los adaptadores FTDI entregan los datos a Windows cada 16 ms por defecto (el temporizador de latencia en la configuración avanzada del puerto), así que una trama puede partirse en el límite del búfer o dos tramas cortas entregarse juntas. Los bytes están intactos; la aplicación debe reensamblar por longitud o delimitador, no por llamada de lectura.

Las marcas de tiempo aclaran cuál de ellas es. Cada paquete en el monitor lleva la hora con precisión de milisegundos y el tiempo transcurrido desde el paquete anterior, así que una trama partida se ve como dos paquetes separados unos milisegundos, y una conmutación tardía como una respuesta que empieza un byte corta. Para MODBUS, el complemento MODBUS (en inglés) muestra la petición y la respuesta en bruto junto a los valores decodificados y señala el CRC.

Un byte recibido a la velocidad equivocada falla la comprobación de trama, y el receptor lo notifica como 0xFF, mostrado como ÿ, o como otro valor fijo. Cuando todos los bytes salen iguales, la velocidad está muy lejos, por ejemplo 9600 frente a 115200. Recorra las velocidades estándar mientras el dispositivo envía; el texto se vuelve legible en la correcta. Si los símbolos cambian con los datos pero nunca son correctos, la velocidad está cerca y lo que falla es la paridad o los bits de parada.

Sí. La paridad y los bits de parada producen caracteres erróneos sueltos; una masa de señal ausente o una línea con ruido produce errores que van y vienen; el control de flujo por software quita bytes de los datos binarios; un adaptador que falla da datos limpios un rato y luego basura. Las comprobaciones 3 a 5 lo cubren en orden.

RS485 añade a los mismos bytes un bus semidúplex compartido. Las líneas A y B intercambiadas, un terminador ausente en un tramo largo, la falta de masa común entre el conversor y los dispositivos, dos esclavos con la misma dirección o un conversor que conmuta tarde producen errores que un enlace RS232 punto a punto nunca ve. Reduzca el bus a un dispositivo y un conversor, y luego añada los dispositivos de uno en uno.

El primer sospechoso es el control de flujo por software: con XON/XOFF activado, los bytes 0x11 y 0x13 se tratan como caracteres de control y nunca llegan a la aplicación. El control de flujo por hardware con un cable sin las líneas RTS y CTS provoca huecos, no pérdidas. Si ninguno está activado, compare la vista HEX del monitor con lo que recibe la aplicación; cuando el monitor muestra los bytes y la aplicación no, es la rutina de lectura de la aplicación la que los descarta.

No. Los valores de la pestaña «Configuración de puerto» del Administrador de dispositivos son valores predeterminados para los programas que no fijan los suyos; la mayoría de los programas fijan la velocidad y la trama cada vez que abren el puerto. Lo que Windows sí cambia es el número COM de un adaptador USB tras una actualización del controlador o en otra toma USB, lo que envía su programa al dispositivo equivocado. La comprobación 2 trata ese caso.