ASCII para datos de PLC: códigos decimales, hexadecimales y de control

ASCII sigue siendo común en los proyectos de PLC porque muchos dispositivos industriales intercambian texto un byte a la vez. Los lectores de códigos de barras, las impresoras de etiquetas, las básculas, los variadores, las pasarelas serie y los terminales de operador suelen representar comandos y mediciones como códigos de caracteres. Los ingenieros que pueden pasar de caracteres a valores decimales y bytes hexadecimales solucionan estos enlaces más rápidamente.

Qué define ASCII

El código estándar estadounidense original para el intercambio de información es un conjunto de caracteres de siete bits. Define 128 valores, numerados del 0 al 127. Los valores del 0 al 31 y el 127 son caracteres de control. Los valores del 32 al 126 son caracteres imprimibles, incluidas letras, dígitos, signos de puntuación y el espacio.

La especificación RFC 20 alojada por el IETF documenta las posiciones de los códigos y sus significados previstos. Los sistemas modernos suelen almacenar un carácter ASCII en un byte de ocho bits. El bit más significativo permanece en cero para el ASCII estándar.

Decimal, hexadecimal y binario son el mismo byte

Una etiqueta de PLC puede mostrar el mismo valor en varios formatos numéricos. La letra mayúscula A es 65 en decimal, 41 en hexadecimal y 01000001 en binario. El dígito 0 es 48 en decimal o 30 en hexadecimal. No son caracteres diferentes. Son distintas representaciones del mismo patrón numérico.

El hexadecimal resulta útil durante la puesta en marcha porque un byte cabe en dos dígitos hexadecimales. Las capturas de paquetes, los monitores serie y los manuales de dispositivos también suelen mostrar los valores de los bytes en hexadecimal. El decimal suele ser más sencillo cuando las instrucciones del PLC esperan constantes enteras.

Los códigos de control importan en los mensajes industriales

Muchos protocolos serie utilizan caracteres de control como delimitadores. El retorno de carro es 13 en decimal o 0D en hexadecimal. El avance de línea es 10 en decimal o 0A en hexadecimal. El inicio de texto es 02 en hexadecimal, mientras que el fin de texto es 03 en hexadecimal. Un dispositivo puede ignorar un comando válido si falta el terminador requerido.

No dé por sentado que todos los dispositivos utilizan CR/LF. Algunos requieren solo CR. Otros utilizan un delimitador imprimible, una longitud de mensaje fija o un byte de suma de comprobación. Confirme la trama exacta en el manual de protocolos del fabricante.

Cómo se convierten las cadenas de PLC en matrices de bytes

Las plataformas de PLC almacenan las cadenas de distintas maneras. Algunas colocan la longitud actual antes de los datos de caracteres. Otras reservan una matriz fija y terminan el texto con un byte cero. Cuando los datos atraviesan un límite de protocolo, el dispositivo receptor ve bytes en lugar del tipo de cadena interno del controlador.

Inspeccione tanto la longitud declarada de la cadena como el búfer subyacente. Un byte obsoleto después de la longitud actual puede aparecer en los datos transmitidos si una rutina envía todo el búfer. Borre el destino o transmita solo la cantidad de caracteres activos.

Un método práctico de diagnóstico

1. Capture los bytes transmitidos exactos con un monitor serie, un analizador de protocolos o una página de diagnóstico de la pasarela.
2. Escriba cada byte en hexadecimal y vuelva a asignar los valores imprimibles a caracteres.
3. Marque los bytes de entramado, los terminadores, los separadores, los campos de longitud y las sumas de comprobación.
4. Compare la captura con el manual del dispositivo, incluidos los espacios y el uso de mayúsculas y minúsculas.
5. Repita la captura para un mensaje que funcione correctamente y compare las posiciones de los bytes.

Este enfoque a nivel de byte separa los fallos de formato de los problemas de cableado, velocidad en baudios y paridad. Si la captura muestra texto legible pero incompleto, céntrese en el ensamblaje de la cadena. Si todos los bytes son incorrectos, verifique primero los ajustes físicos y serie.

Errores comunes de implementación

Confundir un dígito con su valor numérico

El carácter “5” es 53 en decimal ASCII, no el valor entero 5. Convertir un número medido a texto requiere una rutina de formateo. Copiar el entero sin procesar en un búfer de caracteres produce en su lugar un byte de control.

Mezclar texto hexadecimal con bytes binarios

El texto “41” contiene dos caracteres: 34 en hexadecimal y 31 en hexadecimal. Un solo byte con el valor 41 en hexadecimal representa la letra A. Determine si el protocolo espera texto hexadecimal legible para personas o datos binarios sin procesar.

Ignorar las codificaciones más allá de ASCII

ASCII abarca las letras inglesas y un conjunto limitado de símbolos. UTF-8 utiliza los mismos valores de byte para los primeros 128 caracteres, pero los caracteres no ASCII utilizan varios bytes. Un dispositivo antiguo puede rechazar esos bytes o contarlos incorrectamente.

Orientación de diseño para código de PLC fácil de mantener

Mantenga el formateo del protocolo en una sola rutina. Asigne nombres a las constantes de los códigos de control en lugar de dispersar literales numéricos por la lógica de escalera o el texto estructurado. Registre el búfer de transmisión final en hexadecimal durante la puesta en marcha. Incluya ejemplos en la documentación del proyecto.

Cuando un protocolo supera el entramado de texto simple, utilice una máquina de estados definida. Realice un seguimiento por separado de la posición de recepción, el tiempo de espera, el estado de la trama y el resultado de la validación. Esto facilita el diagnóstico de los reintentos y los mensajes con formato incorrecto.

Para consultar patrones más amplios de gestión de datos, vea recorrer matrices en sistemas PLC. Para dispositivos en red, la guía sobre la implementación de un dispositivo Modbus TCP añade contexto sobre el entramado y la puesta en marcha.

Lista de comprobación para la puesta en marcha

• Confirme el conjunto de caracteres y el orden de los bytes.
• Verifique los delimitadores y terminadores en hexadecimal.
• Compruebe si el mensaje tiene una longitud fija o si incluye la longitud como prefijo.
• Diferencie el texto hexadecimal imprimible de los datos binarios sin procesar.
• Valide el comportamiento del tiempo de espera, los reintentos y el borrado del búfer.
• Archive una captura de bytes válida junto con los archivos del proyecto.

ASCII es sencillo, pero los fallos industriales suelen ocultarse en un solo byte ausente o interpretado incorrectamente. Trate primero el mensaje como una secuencia de valores numéricos. Conviértalo de nuevo a texto solo después de comprender la trama.