JSON For Your Command/Response Protocol

If you have a device that uses Command/Response protocol and it’s too expensive or will take too long to change it over to some kind of Ethernet, one of the options you might consider is a JSON conversion.

JSON stands for JavaScript Object Notation. It was designed out of a need for a stateful (able to understand current operating states) way to send data between a Browser and a Server device. In the early 2000s, a group of people developed JSON as part of a non-strict Java implementation. But since that time, it’s been tweaked to be a completely language-independent data format.

Here’s some quick information on JSON:

• JSON is simpler, requires fewer constructs and is easier to implement than XML because it has the single purpose of representing data.
• JSON can be thought of as a successor to XML (eXtensible Markup Language). XML is older but is the de facto standard for moving embedded data to server and browser applications.
• JSON is native to Java and JavaScript and compatible with many other types of computer languages.
• JSON structures data as arrays and records, which is a standard way to structure data in many programming languages.
• JSON is more of a data exchange language than XML: it is much better at exchanging data between applications.

Given the popularity of JSON and the ease with which it interfaces with controllers, middleware and cloud systems, it might be wise to use a converter that can convert your proprietary ASCII Command/Response protocol into JSON objects. It’s not an end-all as the receiver must still decode the operations specified in the commands, but it allows you to more easily communicate your commands to other systems.

Let’s look at an example. Let’s assume we have a two command protocol: Start x,y and Stop. Sending these commands over TCP means that we embed “Start 100,2” or “Stop” in a TCP packet and ship it off to a destination that must use some sort of tokenizer or scripting language to decode these commands. If instead, we shipped {“Cmd”: “Start”, “Parm1”:100, “Parm2”:2} in that TCP packet, we’ve made it much easier for the receiver to process. The only conversion that needs to be done is to match the ASCII “Start” command to our command list. Both parameters are already converted and in memory as integers. It’s simpler for your customers, which means faster to implement and a less costly solution.

If you have an ASCII Command/Response protocol, you need to contact one of the application engineers at Real Time Automation to discuss how you can use your proprietary protocol and send it to controllers over EtherNet/IP, PROFINET IO or Modbus TCP, or send it to middleware, IT applications, or using JSON. Our team specializes in assisting you with keeping your proprietary protocol operating as long as you can and avoiding a redesign that will cost you time and money.

Our team is waiting to hear from you at 800-249-1612 or at solutions@rtautomation.com.