Future of ASCII Data

ASCII, as you know from my previous columns, has been with us for a long time. It’s been key to all the barcoding, labeling and printing we’ve done over the last thirty years. Where would the packaging industry be without barcoding and printing of ASCII characters? What would we do if we couldn’t move barcodes into PLCs?

But things change. Nothing lasts forever. Is ASCII doomed like so many technologies we’ve used over the years?

If you’re an ASCII aficionado, as I am, don’t worry – ASCII isn’t going away. As long as we need to move strings around the factory floor, we’ll always have ASCII. People need string type information to communicate and that means that we’ll have ASCII data. Until something radically new comes along, barcode readers will be reading barcodes and printers will be printing strings and those strings will have to move. They’ll move between all sorts of devices: controllers, printers, labelers, barcode readers, enterprise applications, cloud servers and more.

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 RS232 and RS485, sometimes with protocols like to move Modbus data to PLCs and sometimes without. 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 is more and more the standard way barcodes get into PLCs. USB is the choice for much of this because it’s faster than the serial technologies, more reliable and less expensive. USB is limited by distance and connectivity issues inherent in the technology.

The better choice, of course, is Ethernet. Ethernet is the default medium (and it is only a medium) for the factory floor. Anything and everything on the manufacturing floor will have Ethernet in the future (yes – even sensors, but that’s an article for another day). To use Ethernet and TCP/IP requires we implement some sort of application layer to use when moving ASCII data. It’s bad practice, as you know from my previous articles, to just send ASCII without identifying how it’s encoded.

Whatever we use, it has to be reliable, it must be sequenceable, it must support multiple ASCII encodings, and it must be secure. Other than support for multiple ASCII encodings, these requirements fit many applications on the factory floor. All application layers that send messaging data over TCP are reliable. TCP has built in CRC (cyclic redundancy check) that ensure reliability.

But none of the standard technologies we use today can provide sequencing of the data. It’s important with barcoding and printing that we keep the ASCII messages in the correct order – most of our current technologies don’t do that. TCP does, but there’s no encoding information when you send ASCII over TCP. UDP and EtherNet/IP, ProfiNet IO, Modbus TCP, MQTT – none of them ensure that the data is sequential. That has to be built into the device providing the data. And none of them provide the support for multiple encodings, which is what’s needed to support foreign language strings.

The one architecture that really provides the most functionality for ASCII strings is OPC UA. OPC UA is reliable – messages are transported over TCP. OPC UA is as secure as you want it to be: the installation manager gets to pick what type of security is supported, what types of credentials are needed to access a device, or even if security is supported at all. OPC UA provides the ability to select encodings and select them at the detail level for a particular attribute.

OPC UA can also provide the sequencing. OPC UA Attributes can be arrays containing groups of strings or single attributes. And the ASCII data can be encoded in multiple ways – and that is done separate from your application. Your data can be encoded in json or xml or as a csv or ftp file. Because OPC UA is flexible, encodings like everything else, can be added as desired.

You can even dedicate special endpoints that support those encodings. One endpoint can be the json endpoint and another can be the xml endpoint. The Client device can decide which to support.

ASCII has been on the factory floor for a long time and it will be here for a long time. And OPC UA is the architecture that is going to power it!

John