An Introduction to

ASCII

ASCII Data Encoding

Traditional ASCII field devices like barcode scanners, RFID readers and weigh scales generate a raw analog voltage based on physical input such as light reflection (barcode scanners), radio frequency induction (RFID) or mechanical pressure (weigh scales). An internal analog-to-digital converter (ADC) translates this electrical signal into a digital mathematical value.

When this input is received, the device’s processor maps the value to its corresponding character using an internal ASCII lookup table and then translates it into a standard 7-bit or 8-bit binary pattern. This binary data is handed off to the communication interface to be sent to the receiver, typically a PLC or ASCII gateway. The data transmission depends on the device’s physical interface:

• For serial devices, the binary data is sent to a Universal Asynchronous Receiver-Transmitter (UART) that wraps each character in a frame and pulses the signal down the wire bit by bit
• For ethernet devices, the binary data is handed to an Ethernet controller, which bundles the characters into a TCP/IP packet

ASCII Reference Table

The 128-character ASCII reference table is shown below.

ASCII Messaging and Framing

Once a physical value is encoded into ASCII characters, it must be packaged and transmitted. Depending on the physical layer, the data is delivered either as a stream of individual characters or as a bundled data packet.

Serial ASCII

Bit-by-Bit Transmission

Because serial wires can only carry one signal at a time, the UART sends data in a bitstream. While the original ASCII standard is a 7-bit code that includes an 8th “parity” bit for error detection, most modern industrial applications use an 8-bit format.

In standard serial communication, the least significant bit (LSB) is sent first, followed by the remaining bits and ending with the most significant bit (MSB). Understanding this bit order is crucial for troubleshooting and ensuring data is not misinterpreted by a PLC.

Serial ASCII Frame Structure

In serial ASCII, each character is wrapped in a data frame that defines the start, order, and end of the character.

• Start Bit: A single bit (logic “0”) that signals to the receiver’s UART that a character is coming
• Data Bits: The binary data for the character, sent with the least significant bit (LSB) sent first
• Stop Bit: A final bit (logic “1”) that signals the end of the character and allows the timing to reset for the next character

The character-by-character delivery of serial ASCII strings requires PLCs to catch individual frames and manually reassemble them into a usable string, which is CPU-intensive and prone to timing errors. This delivery method causes a multitude of challenges for system integrators but is easily handled by ASCII gateways.

Ethernet ASCII

Packetized Delivery

In ASCII over Ethernet, the individual start and stop bits are stripped away. Instead of streaming characters one-by-one, the device bundles the entire string into a TCP/IP packet. This packet protects the data with its own internal error-checking and headers, delivering the entire message to the PLC all at once (though the PLC must still manage the TCP socket connection).

ASCII Message Structure

The ASCII message frame uses non-printable control characters to help the receiver identify when one complete data set ends and the next begins. The start delimiter, STX, is an optional character that signals a new data packet is starting. The most common end-of-message delimiters are the Carriage Return (CR) or Line Feed (LF) characters.

ASCII Message Example: Weigh Scale Payload

To a PLC or ASCII gateway, messages are processed as a sequence of hexadecimal values. Suppose a weigh scale measures a value of 125.5. If you were to look at the message, [STX]125.5[CR][LF], through a serial sniffer, it would appear as 02 31 32 35 2E 35 0D 0A.

ASCII Test Tools

When you come across a device using ASCII commands to operate, it is advantageous to have tools that allow you to visualize the commands on the wire. For ASCII over Ethernet, our team uses SocketTest. For serial-based ASCII, we recommend MTTTY Serial Terminal. Having both of these tools handy can be useful in the field to help resolve quite a few headaches. Best of all, they’re free.

ASCII Devices

ASCII-based devices largely come from two camps: devices that are text centric and devices that originally interacted with a PC based application.

Text-Centric ASCII Devices

Text-centric ASCII devices read or display human readable characters. Examples include barcode scanners, weigh scales, printers, RFID readers and LED displays.

ASCII Command Response Devices

In industrial automation we leverage open protocols like Modbus, EtherNet/IP and PROFINET to move messages reliably. For many devices, the interface between the node and PC was a custom ASCII protocol. This is accomplished by defining a set of commands and responses. Below are some examples of Command (CMD)/Response (RSP) strings:

CMD:GO
RSP:OK.

CMD: Get all?
RSP: 79.8,44.3,186_c,ON,Error2

CMD: ACQ?
RSP: ACQ:ENZERO=5,VMIN=6,AVG=8.99

CMD: ACQ?ENZERO,VMIN
RSP: ACQ:ENZERO=5,VMIN=6

ASCII Physical Layers

Now that we know what ASCII is and what devices utilize the 7-bit character encoding, let’s talk about the two most common physical layers used to pass ASCII messages.

ASCII over Serial

For most of its life, ASCII communication occurred over a serial physical layer. Often that physical layer was RS-232, where the ASCII characters were converted into binary bits and transmitted by a signal voltage of +/- 3-13VDC. In RS-232, for example, negative voltage represents a logic “1” (mark) while a positive voltage represents a logic “0” (space).

The main limitation was that devices needed to be close together and most communication was 1-to-1, forcing early PLCs to require numerous serial ports. Modern PLCs have largely done away with native serial ports.

ASCII over Ethernet

In an Ethernet-enabled device, ASCII characters aren’t sent bit-by-bit via a UART. Instead, the device opens a TCP Socket (usually on a specific port like 2101 or 5000) and sends the entire ASCII message as a single data packet.

Ethernet TCP/IP is more reliable over longer distances than its serial counterparts. Serial devices utilizing ASCII messages were among the first to swap physical layers to Ethernet. The same ASCII data payload is simply placed inside a standard TCP/IP packet. This offers the additional benefit of a network that supports multiple nodes, but it requires the receiver (the PLC) to manage connection states and port numbers rather than just monitoring a voltage signal.

Challenges of ASCII in Industrial Automation

Generally speaking, ASCII is challenging to deploy in an automated control system. Many industrial devices, such as barcode scanners, RFID readers, weigh scales, displays and other legacy devices only communicate in ASCII, creating several major roadblocks for modern control networks.

• Edge Device Ubiquity: The overwhelming majority of edge devices still rely on raw ASCII. These devices prioritize low-cost, universal compatibility and lack the onboard processing power required for modern industrial protocols and native compatibility with ethernet-enabled PLCs.
• Unstructured Data: Modern PLCs are designed for structure data organized into tags or registers. ASCII devices send out unstructured text strings at an undefined length that are meaningless to a PLC in its raw form.
• Hardware Incompatibility: Modern PLCs are largely Ethernet-based and do not provide a serial port, yet many edge devices still rely on legacy serial interfaces. Workaround solutions, such as in-rack serial modules, take up physical space and require complex hardware configuration.
• Burden of Custom Coding and Maintenance: PLCs aren’t designed to manipulate string data. Integrating ASCII data directly into a PLC requires custom parsing logic to be written and maintained within PLC programs.
• Scan Time and CPU Overhead: Constant string manipulation is CPU-intensive and can consume valuable processing power, potentially impacting the PLC’s overall scan time and deterministic performance.
• Socket Persistence & Timeouts: Unlike “always-on” serial, Ethernet ASCII requires a managed connection. A PLC must be programmed to detect TCP socket drops and manually re-establish the connection.

ASCII Gateways

ASCII gateways eliminate the most challenging elements of leveraging ASCII data in PLCs. Sitting between your raw ASCII devices and your control network, the gateway passes only the data payload (without any delimiters) to the PLC. This offloads the grunt work of parsing ASCII strings to the gateway, which then writes the payload values directly to your PLC data tables.

Going beyond a simple one-to-one connection, ASCII gateways also provide advanced data manipulation. They take noisy ASCII strings and can parse them into individual data points before send them to the PLC. Conversely, they can concatenate multiple data points from the PLC into a perfectly formatted string for ASCII display devices or printers. This approach ensures your PLC scan time remains deterministic and that your logic stays clean and easy to maintain.

The History Behind ASCII

It was way back in 1961 when a bunch of white-shirted, black-tied engineers at IBM led the effort at the American National Standards Institute (ANSI) to develop a single common way to interchange numbers between computers. It was a mess before that. Different vendors not only represented letters and numbers differently in their computers, but they used different numbers of bits. A lot of vendors used 6 bits (that’s just 64 different combinations!).

The IBM guys convinced everyone that all computers should represent letters, numbers and special characters in the same way. Their effort led to the American Standard Code for Information Interchange, or ASCII (pronounced AS-kee).

In 1968, President Lyndon Johnson signed a memorandum adopting ASCII as the standard for federal computers, but it wasn’t until Intel invented eight-bit microprocessors in the early 1970s that eight bits and ASCII became common. By the end of that decade, IBM 360 computers (what every Fortune 500 company used) were using an old EBCDIC standard (Extended Binary Coded Decimal Interchange Code), which was finally retired with the introduction of the personal computer in 1981.

Where is ASCII Today?

ASCII is still all around us in RFID devices, barcode scanners and printers. Heck, it’s even used in weather stations to send data. It’s the only data format that can be universally decoded by any computer on the planet.

ASCII was the most common encoding used on the Internet until it was taken over by Unicode in the early 2000s. ASCII formed the foundation of Unicode and was therefore included in its set as well as its successor, UTF-8, and the standard encodings being created today.

The Future of ASCII

If you’re an ASCII aficionado, don’t worry. Even after 75 years, ASCII isn’t going away. Strings will continue to move between all sorts of devices: controllers, printers, labelers, barcode readers, enterprise applications, cloud servers and more. As long as we need to move strings around the factory floor, as long as people need string type information to communicate, as long as barcode readers read barcodes and printers print strings, we’ll always have ASCII.

The pertinent question for all of us is: how are we going to move that ASCII data in the future? In the past, we used RS-232 and RS-485, sometimes with protocols like Modbus, to move data to PLCs. Those technologies worked but they were slow and unreliable. Today, we’ve replaced much of that with USB. Sending ASCII data into PLCs over USB has become the standard way barcodes get into PLCs. USB is faster than the serial technologies, more reliable and less expensive. However, USB is limited by distance and connectivity issues inherent in the technology.

Today, we’ve replaced much of that with USB. Sending ASCII data into PLCs over USB has become the standard way barcodes get into PLCs. USB is faster than the serial technologies, more reliable and less expensive. However, USB is limited by distance and connectivity issues inherent in the technology.

The better choice, of course, is Ethernet. Ethernet is the default physical layer for the factory floor. Anything and everything on the manufacturing floor will have Ethernet in the future, even sensors. Note that using Ethernet and TCP/IP requires implementing some sort of application layer to move ASCII data.