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.

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.

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.

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. 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.