ASCII to the Cloud Part 1

Even though it’s 2018, we still find ASCII devices on the factory floor. And we always will. If you think about it, anything with a label contains ASCII data. Every barcode reader is really just a series of ASCII characters. As long as humans communicate in letters and numbers, we’ll need to move ASCII data around the manufacturing environment. These characters need to be stored, they need to be printed, and they sometimes need to be converted into numeric data. For example, a lot of old scales send their scale data as a series of ASCII characters like “2 1 . 6 5”. ASCII characters like that need to be converted and stored as a floating point number.

But moving ASCII data isn’t as straightforward as it could be. In years past, a lot of ASCII data was transmitted over serial communications: RS232 and RS485 links. RS232, a ubiquitous component of every processor and PC, was prone to a lot of noise. RS485 links were prone to problems stemming from loose connections and faulty wiring. Those kinds of issues were extremely difficult to correct. Now, a lot of these systems have migrated to USB, which provides not only better error management but also better integration.

ASCII data can also be moved over EtherNet/IP, PROFINET IO, and Modbus TCP. None of these technologies make it easy to move ASCII data, but it can be managed. In EtherNet/IP and PROFINET IO, you can define an ASCII value and move ASCII data to higher level systems using their messaging capabilities, but that only works well for relatively small amounts of data. PLCs can gather ASCII data from these kinds of technologies, but they are just not very good at extracting information from them or performing table lookups.

Modbus and Modbus TCP are probably the worst technologies for moving ASCII data. In Modbus, ASCII characters are usually stored two characters to a word. One half of the 16-bit Modbus unsigned integer register is used to store a character (8-bit) while the other half stores the next character. The receiving system must know how the data is stored: Big Endian or Little Endian. In Big Endian (Modbus default), data is stored in high byte/low byte order. In Little Endian, data is stored in low byte/high bytes order. A receiver must not only know the order, but it must use processor bandwidth to extract the data bytes from the Modbus registers to do anything with them.

These systems are marginally adequate for moving data between PLCs, barcode scanners, other ASCII devices, and HMIs. They work and you can get the job done. Control Engineers and System Integrators have been spending time and money processing ASCII data for a long time now.

But now, in 2018, we need to move that ASCII data beyond the factory floor to some higher-level system. We need to move it to an Enterprise Server or the Cloud. In that case, you are really at a loss. There are no better mechanisms for moving ASCII data between the factory floor and the Cloud then there are between systems on the factory floor.

This is a very real problem in any number of applications. In lots of situations, ASCII data is related to the quality, performance, or identity of products. This data, some binary and some ASCII, needs to be transferred to long term Cloud storage. Getting it there has, in the past, been a difficult problem for a lot of industrial users. As we discussed, PLCs are not good mechanisms for this. They don’t have a good way to move that data into the Enterprise and the Cloud.

And that’s what I will discuss in the next article in this series.