ASCII Command Response Devices

If you’re a little older you can remember those old Cathode Ray Televisions everyone had in their house. In the days before flat panel displays, CRTs were 30 inches deep and weighed a ton. Just another example of devices being more complex, more expensive and heavier in the past.

There are still industrial devices in use that are like this. They are not all that heavy but many of them still use old-style ASCII communications. In the days before DeviceNet, Profibus DP and Modbus, custom ASCII communications was very popular. Sometimes the commands would be as simple as “$GO” to start a drive but often they would be fairly complicated with multiple parameters such as “W3 52,175.6,.3345”.

Custom ASCII was found in everything from drives to chart recorders to weigh scales and barcode readers.  And, over time, those ASCII command sets expanded into extensive command lists. With the unsophisticated microprocessors of the 80s, 90s, and 2000s and before standard communication technologies, that was a very reasonable way to do things.

Now, of course, that seems awfully ancient. There’s no argument at how old these devices are but in manufacturing, many of the jobs we need to be done don’t change. Many of these old devices are still around. They still work well and people want to use them. Sometimes the manufacturers of these devices have lost interest in them, they don’t have the money or time to invest in a complete redesign – whatever the reason, just like the old TVs, they’re not going away. Manufacturers and system integrators need to deal with them. The problem that they have is that today’s controllers don’t have a serial port (RS232 or RS485) and a way to generate those custom ASCII communications protocols.

If you have one of these ASCII devices, there are things you can do to make your device more easily integrated into today’s manufacturing system. Two ideas you might consider are to simply adapt your protocol into something more palatable to today’s control system or convert it to a more functional protocol technology.

Adapting your protocol means simply converting your ASCII commands into sometime like JSON or XML. JSON is an object-oriented, ASCII version of XML. Where XML uses tags of the format <Temp>52</Temp>, JSON uses curly braces: {“name”:”Emily”, “age”:34, “car”:null}. The advantage to JSON is that modern languages like Java can implicitly convert JSON text in a TCP packet into memory variables that can be logically processed by code.

Converting your protocol means to replace it and make your device look like a Modbus TCP Slave, an EtherNet/IP Adapter or PROFINET IO end device. To do that, some subset of your ASCII command set must be mapped into the base data representation of that protocol.

Either approach can extend the life of your current ASCII device whether you have the intention of replacing it in the future or you just want to continue selling it as long as you can.

Neither one of these approaches is difficult but they do require some sort of hardware and software to make that happen. The application experts at RTA work with customers like this all the time, so if you have one of these devices, contact them to see how they can help you. Call RTA at 800-249-1612 and speak to an application engineer, email solutions@rtautomation.com or visit contact us to learn more.