ASCII for PLC Data: Decimal, Hex, and Control Codes

ASCII remains common in PLC projects because many industrial devices exchange text one byte at a time. Barcode readers, label printers, scales, drives, serial gateways, and operator terminals often represent commands and measurements as character codes. Engineers who can move between characters, decimal values, and hexadecimal bytes troubleshoot these links faster.

What ASCII defines

The original American Standard Code for Information Interchange is a seven-bit character set. It defines 128 values, numbered 0 through 127. Values 0 through 31 and 127 are control characters. Values 32 through 126 are printable characters, including letters, digits, punctuation, and space.

The IETF-hosted RFC 20 specification documents the code positions and their intended meanings. Modern systems usually store an ASCII character in an eight-bit byte. The highest bit stays zero for standard ASCII.

Decimal, hexadecimal, and binary are the same byte

A PLC tag may display the same value in several number formats. The capital letter A is decimal 65, hexadecimal 41, and binary 01000001. The digit 0 is decimal 48 or hexadecimal 30. These are not different characters. They are different views of the same numeric pattern.

Hexadecimal is useful during commissioning because one byte fits into two hex digits. Packet captures, serial monitors, and device manuals also tend to show byte values in hex. Decimal is often easier when PLC instructions expect integer constants.

Control codes matter in industrial messages

Many serial protocols use control characters as delimiters. Carriage return is decimal 13 or hex 0D. Line feed is decimal 10 or hex 0A. Start of Text is hex 02, while End of Text is hex 03. A device may ignore a valid command if its required terminator is missing.

Do not assume every device uses CR/LF. Some require CR only. Others use a printable delimiter, a fixed message length, or a checksum byte. Confirm the exact frame in the manufacturer’s protocol manual.

How PLC strings become byte arrays

PLC platforms store strings differently. Some place the current length before the character data. Others reserve a fixed array and terminate text with a zero byte. When data crosses a protocol boundary, the receiving device sees bytes rather than the controller’s internal string type.

Inspect both the declared string length and the underlying buffer. A stale byte beyond the current length can appear in transmitted data if a routine sends the full buffer. Clear the destination or transmit only the active character count.

A practical diagnostic method

1. Capture the exact transmitted bytes with a serial monitor, protocol analyzer, or gateway diagnostic page.
2. Write each byte in hexadecimal and map printable values back to characters.
3. Mark framing bytes, terminators, separators, length fields, and checksums.
4. Compare the capture with the device manual, including spaces and letter case.
5. Repeat the capture for a known-good message and compare byte positions.

This byte-level approach separates formatting faults from wiring, baud-rate, and parity problems. If the capture shows readable but incomplete text, focus on string assembly. If every byte is wrong, verify physical and serial settings first.

Common implementation errors

Confusing a digit with its numeric value

The character “5” is ASCII decimal 53, not the integer value 5. Converting a measured number to text requires a formatting routine. Copying the raw integer into a character buffer produces a control byte instead.

Mixing hexadecimal text with binary bytes

The text “41” contains two characters: hex 34 and hex 31. A single byte with value hex 41 represents the letter A. Decide whether the protocol expects human-readable hex text or raw binary data.

Ignoring encoding beyond ASCII

ASCII covers English letters and a limited symbol set. UTF-8 uses the same byte values for the first 128 characters, but non-ASCII characters use multiple bytes. A legacy device may reject those bytes or count them incorrectly.

Design guidance for maintainable PLC code

Keep protocol formatting in one routine. Name constants for control codes instead of scattering numeric literals through ladder logic or structured text. Log the final transmit buffer in hex during commissioning. Include examples in the project documentation.

When a protocol grows beyond simple text framing, use a defined state machine. Track receive position, timeout, frame state, and validation result separately. This makes retries and malformed messages easier to diagnose.

For broader data-handling patterns, see looping through arrays in PLC systems. For networked devices, the guide to deploying a Modbus TCP device adds framing and commissioning context.

Commissioning checklist

• Confirm the character set and byte order.
• Verify delimiters and terminators in hex.
• Check whether the message is fixed-length or length-prefixed.
• Distinguish printable hex text from raw binary data.
• Validate timeout, retry, and buffer-clearing behavior.
• Archive a known-good byte capture with the project files.

ASCII is simple, but industrial failures often hide in one missing or misread byte. Treat the message as a sequence of numeric values first. Convert it back to text only after the frame is understood.