ASCII para dados de PLC: decimal, hexadecimal e códigos de controle

ASCII continua sendo comum em projetos de PLC porque muitos dispositivos industriais trocam texto um byte por vez. Leitores de código de barras, impressoras de etiquetas, balanças, inversores, gateways seriais e terminais de operação geralmente representam comandos e medições como códigos de caracteres. Engenheiros que conseguem alternar entre caracteres, valores decimais e bytes hexadecimais diagnosticam essas conexões mais rapidamente.

O que ASCII define

O American Standard Code for Information Interchange original é um conjunto de caracteres de sete bits. Ele define 128 valores, numerados de 0 a 127. Os valores de 0 a 31 e o 127 são caracteres de controle. Os valores de 32 a 126 são caracteres imprimíveis, incluindo letras, dígitos, pontuação e espaço.

A especificação RFC 20 hospedada pelo IETF documenta as posições dos códigos e seus significados pretendidos. Os sistemas modernos geralmente armazenam um caractere ASCII em um byte de oito bits. O bit mais significativo permanece zero no ASCII padrão.

Decimal, hexadecimal e binário são o mesmo byte

Uma tag de PLC pode exibir o mesmo valor em vários formatos numéricos. A letra maiúscula A é 65 em decimal, 41 em hexadecimal e 01000001 em binário. O dígito 0 é 48 em decimal ou 30 em hexadecimal. Esses não são caracteres diferentes. São diferentes representações do mesmo padrão numérico.

O hexadecimal é útil durante o comissionamento porque um byte cabe em dois dígitos hexadecimais. Capturas de pacotes, monitores seriais e manuais de dispositivos também tendem a mostrar valores de bytes em hexadecimal. O decimal costuma ser mais fácil quando as instruções do PLC esperam constantes inteiras.

Códigos de controle são importantes em mensagens industriais

Muitos protocolos seriais usam caracteres de controle como delimitadores. Retorno de carro é 13 em decimal ou 0D em hexadecimal. Alimentação de linha é 10 em decimal ou 0A em hexadecimal. Início do Texto é 02 em hexadecimal, enquanto Fim do Texto é 03 em hexadecimal. Um dispositivo pode ignorar um comando válido se o terminador exigido estiver ausente.

Não presuma que todo dispositivo usa CR/LF. Alguns exigem apenas CR. Outros usam um delimitador imprimível, um comprimento fixo de mensagem ou um byte de soma de verificação. Confirme o quadro exato no manual de protocolo do fabricante.

Como strings de PLC se tornam arrays de bytes

As plataformas de PLC armazenam strings de maneiras diferentes. Algumas colocam o comprimento atual antes dos dados dos caracteres. Outras reservam um array de tamanho fixo e terminam o texto com um byte zero. Quando os dados atravessam uma fronteira de protocolo, o dispositivo receptor vê bytes, e não o tipo de string interno do controlador.

Inspecione tanto o comprimento declarado da string quanto o buffer subjacente. Um byte antigo além do comprimento atual pode aparecer nos dados transmitidos se uma rotina enviar o buffer inteiro. Limpe o destino ou transmita apenas a quantidade de caracteres ativos.

Um método prático de diagnóstico

1. Capture os bytes transmitidos exatos com um monitor serial, analisador de protocolo ou página de diagnóstico do gateway.
2. Escreva cada byte em hexadecimal e converta os valores imprimíveis novamente em caracteres.
3. Marque os bytes de enquadramento, terminadores, separadores, campos de comprimento e somas de verificação.
4. Compare a captura com o manual do dispositivo, incluindo espaços e maiúsculas e minúsculas.
5. Repita a captura para uma mensagem conhecida como correta e compare as posições dos bytes.

Essa abordagem em nível de byte separa falhas de formatação de problemas de cabeamento, taxa de transmissão e paridade. Se a captura mostrar texto legível, mas incompleto, concentre-se na montagem da string. Se todos os bytes estiverem errados, verifique primeiro as configurações físicas e seriais.

Erros comuns de implementação

Confundir um dígito com seu valor numérico

O caractere “5” é 53 em decimal ASCII, não o valor inteiro 5. Converter um número medido em texto exige uma rotina de formatação. Copiar o inteiro bruto para um buffer de caracteres produz um byte de controle.

Misturar texto hexadecimal com bytes binários

O texto “41” contém dois caracteres: 34 em hexadecimal e 31 em hexadecimal. Um único byte com valor 41 em hexadecimal representa a letra A. Decida se o protocolo espera texto hexadecimal legível por humanos ou dados binários brutos.

Ignorar codificações além do ASCII

ASCII abrange letras do inglês e um conjunto limitado de símbolos. UTF-8 usa os mesmos valores de bytes para os primeiros 128 caracteres, mas caracteres não ASCII usam vários bytes. Um dispositivo legado pode rejeitar esses bytes ou contá-los incorretamente.

Orientações de projeto para código de PLC fácil de manter

Mantenha a formatação do protocolo em uma única rotina. Dê nomes às constantes dos códigos de controle em vez de espalhar literais numéricos pela lógica ladder ou pelo texto estruturado. Registre o buffer final de transmissão em hexadecimal durante o comissionamento. Inclua exemplos na documentação do projeto.

Quando um protocolo ultrapassar o simples enquadramento de texto, use uma máquina de estados definida. Acompanhe separadamente a posição de recebimento, o tempo limite, o estado do quadro e o resultado da validação. Isso facilita o diagnóstico de novas tentativas e mensagens malformadas.

Para padrões mais amplos de manipulação de dados, consulte percorrer arrays em sistemas de PLC. Para dispositivos em rede, o guia sobre implantação de um dispositivo Modbus TCP acrescenta contexto sobre enquadramento e comissionamento.

Lista de verificação do comissionamento

• Confirme o conjunto de caracteres e a ordem dos bytes.
• Verifique os delimitadores e terminadores em hexadecimal.
• Confira se a mensagem tem comprimento fixo ou se o comprimento vem precedido.
• Diferencie texto hexadecimal imprimível de dados binários brutos.
• Valide o comportamento de tempo limite, novas tentativas e limpeza do buffer.
• Arquive uma captura de bytes conhecida como correta junto com os arquivos do projeto.

ASCII é simples, mas as falhas industriais muitas vezes se escondem em um único byte ausente ou interpretado incorretamente. Trate a mensagem primeiro como uma sequência de valores numéricos. Converta-a novamente em texto somente depois que o quadro for compreendido.