ASCII Device Communication in 2018

I would bet some of you reading this today are using Windows 8, Windows 7 or some even older version of Windows. If you’re not, I bet you know of someone who is using one of those old versions. What’s more, I bet five years from now, you’ll still know people with old Windows versions. The same applies to old cars, old televisions, old phones and everything else. I have an uncle who has a Snoopy phone from 1987 he won’t part with under any circumstances.

It takes a long time for old electronics to die. Sometimes it becomes more valuable. I heard recently of someone who was looking at burner phones and thought, why not a burner car (chevynovaburnercars.com)? In today’s world where every car is connected, there may be an opportunity for a car that could not track you as long as you were able to manually shift and wanted to roll down the passenger window by hand, listen to an AM/FM radio and experience life with no air conditioning.

The point is old products and technologies never really die. ASCII, which is going on 70 some years now, is one of those old technologies that just won’t die. As long as we have humans that need to read the side of boxes, read labels on beer bottles and know the contents of the Ketchup we buy, we’ll be moving ASCII data around the factory floor.

Now PLCs don’t do this very well. They don’t really have the power, resources or instruction sets necessary to manipulate ASCII data. For example, PLCs have different ways of storing ASCII data in memory. Some of them will store it as Integer data by combining two characters together. That leads to all sorts of problems. PLCs also can’t easily search through ASCII data, combine two strings, truncate a string … etc. ASCII data is a nightmare for PLC programmers. It’s a little better today as most PLCs have ASCII data types.

In 2018, we need to move ASCII data from Enterprise Clients to printers, from barcode readers to Enterprise Clients and more. None of the protocols we’ve used over the years do this very well. EtherNet/IP, PROFINET IO, Modbus TCP, DeviceNet, Profibus DP or any other one you can name moves ASCII data as an ASCII data type. They all treat it as a series of Integers. That makes getting to where it needs to go very difficult.

OPC UA is one of the few technologies that can treat ASCII data properly. The Value attribute of a Variable in OPC UA can be configured as UTF 8. That makes it easier for Clients to use the data because if they know it is a UTF 8 data type, they’ll know exactly how to process it. Unlike most of these other technologies, OPC UA can store and move ASCII data as ASCII data and not data hidden in another data type.

One of the things that has changed for ASCII over the years is the size of data we are moving. In the old days, the strings were pretty short and contained only 7-bit ASCII data. Now, the strings can be large, sometimes as large as 1k, 4k, or even 10k. These larger ones are usually transmitted as CSV files. The unfortunate thing about these large ASCII files is that they require a lot of processor resources to manage. All that byte by byte transfer is taxing on lower end processors.

The other thing that has impacted ASCII in 2018 is we are now an international world. In the old days, everything was English and all English characters could be represented in 7 bits. But today, with Japanese, Chinese and Korean languages, to name a few, we need a lot more than 7-bits to capture these thousands of characters. That’s where UTF 16 and the other UTF encoding standards come in. We need to easily switch a product from English to Korean and that couldn’t be done with your dad’s ASCII data.

ASCII will continue to be a mainstay of factory floor data.

And I’m glad about that.