ASCII Cmd Rsp

I was asked the other day why there are so many factory floor devices using ASCII communications. Even in 2018, it seems like there are still many devices that have some sort of proprietary command–response protocol using ASCII communications. And the more pressing question is: “What do we do about it?”

Thinking about this over the last few days, I’ve come to the conclusion that it’s partly the nature of these devices and partly that factory infrastructure changes so slowly. Let me explain.

When we first started using computers in machines, the concepts of cyclic communications, a push architecture, or a publish/subscribe architecture were unheard of. The concept of a device sending data without it being requested was just nonsense to the developers of the day. The only concept they knew, what everybody knew, was command response. You send a command to a device and the device responds.

And what was sent was always ASCII characters. In that era, binary data was just too difficult to process. Some systems used MSB-LSB (Big Endian) for 16-bit numbers while others used LSB-MSB (Little Endian). A lot of the communication links were 7-bits plus a parity bit, which precluded binary data. ASCII was just the simplest way to implement a control device. You send it a “$GO” and the device starts and a “$STOP” and the device stops. What could be simpler? But, of course, this evolved into devices with hundreds of commands and complicated parameter strings. And that’s why we have devices that are a nightmare to interface.

I was at a Pfizer plant a few years ago, and the control engineer there told me that they have a little of everything you’ve ever heard of and some things that no one has heard of. They have EtherNet/IP, PROFINET IO, DeviceNet, Modbus TCP, and Profibus DP, of course, but they also have little used technologies like Lonworks and oddball things I’ve never heard of like D1 and TSX.

In the factory automation environment, we keep things around for a long, long time. Whether we spend one million, ten million, or fifty million dollars, we want to run that equipment into the ground. And when we build machines to run for years on end, we want technology that’s not only the best fit but that’s going to be around for a long time. Unfortunately, our crystal ball of what’s going to be around for the long term is pretty inaccurate. We pick technologies that appear to be not only functional but stable and well-supported. Many times those end up being awful choices (I’m sure I couldn’t do better). Lonworks, for example, looked to be a real winner for a long time, until it didn’t. It’s hard to predict this stuff.

So those are the two reasons we have so much ASCII communications on the factory floor today. There are just a lot of devices out there that use ASCII command/response protocol, and the devices that use it are going to be around for a long time to come.

But RTA is here to help you. We have a full line of devices to manage ASCII devices and easily integrate them into your control architecture. You can get devices that:

Move ASCII data into AB PLCs over serial
Move ASCII data into AB PLCs over TCP
Move ASCII data into AB PLCs over USB

You can also get devices to:

Move ASCII data into a Modbus Client
Move ASCII data into a PROFINET IO Controller
Move ASCII data into a BACnet MS/TP device

And if you have something really complicated, just visit us on our Contact RTA page or call 800-249-1612 and we’ll get you a custom device to move your data where you want.

We’re known as the ASCII guys for a reason!