ASCII Query/Response Communications

In the earliest days of industrial devices, a controller and an end-device had one option to communicate; Query / Response over RS232 serial communications. Query / Response, or Command / Response, simply means that a controller or master device forms a command and an end-device, receives it, processes it and return a response back to the controller.

Prior to the invention of Modbus, Query / Response was always a proprietary mechanism specific to the manufacturer of the device. I still recall how one company required a signed non-disclosure to get access to their proprietary Query / Response protocol. They were wary of letting just anyone send commands or access the data of their device.

Today, it’s still not uncommon. There are many manufacturing devices that still use query/response communications to pass commands, data, and results between two systems. Even with the popularity of industrial application layer protocols like EtherNet/IP, PROFINET IO, Modbus TCP, and others, there are still thousands of devices still using query/response communications.

Query/Response uses ASCII commands and responses. It originated in the days of the IBM mainframe when people typed on terminals. They typed a message and then hit the return key to send a string to a mainframe computer. All communication, because it was done by humans, was done in standard ASCII.

Key to a Query / Response protocol was the use of terminators; carriage return and newline. A receiver would know when it saw one or both of these characters that it had the end of a message and could process the string. These characters also served to make the strings easier for the humans to read as they caused the display to advance a line and return to the left edge of the screen. Very antiquated today but it still lives on in Microsoft Windows 10. The Search feature and the DOS prompt are remnants of those early days of computing.

Query / Response communications could be as simple or as complicated as the designer liked. It was ultimately flexible. Motor drives might use a command string like “$G 200” to start the motor or set speed and $Stop to stop the motor. The drive might respond with “$R 200” when it’s running or “$X” if stopped. In more complicated systems, the command string was extremely long and cumbersome:

$22,176,435,20222,R56,17,999,52,109

Many Query / Response systems use commas as separators between parameters. The number of parameters used in a command string might vary from zero to hundreds.

Advantages to query response include its simplicity and the ability of humans to monitor the traffic between two systems and easily diagnose problems. The disadvantages were numerous. For one, coding of parsers to identify and separate the parameters from each other was a difficult coding challenge. Not impossible but certainly a challenge requiring some skilled programmer and hours of testing to ensure its accuracy.

Today a number of these old Query / Response systems are still in use but in addition to RS232 and RS484 serial communications, the commands and response are exchanged over USB and TCP. Nearly all controllers are unable to easily communicate with these systems. Few, if any, can parse generic strings like the ones used by these systems to transfer commands and data.

RTA is at the forefront of solving this challenge by providing a tool that can interface to a Query/Response system, interpret the commands and response and make that interpretation available to programmable controllers, IoT systems and SCADA controllers using standard Modbus TCP, EtherNet/IP, PROFINET IO, DeviceNet or PROFIBUS.

If you have one of the Command / Response devices in your shop, call our application engineering team today at 800-249-1612, email Solutions@RTAutomation.com, or simply Contact Us to learn how your device can be integrated into today’s technologies.