ASCII Data over HTTP

ASCII data will be with us forever. It was invented out of necessity in the early days of computers. In those days, every computer manufacturer, and there were a lot of them, invented their own way of storing English characters in a computer (the term ASCII didn’t exist then) . There were all sorts of ways to store data because the size of an element of computer data wasn’t standardized. Some manufacturers used 8 bytes, but others used as many as 48 and as few as 6.

ASCII data was so important that once the computer hardware element size was standardized, the representation for English characters had to be standardized. IBM led the way in 1961, proposing to the American National Standard Institute that 128 codes from 0 to 127 (0 to 7F hexadecimal) be used to represent the standard English characters. Since then, the representation has been extended to include characters from Chinese, Japanese and other languages.

Once ASCII data was standardized, the next big step was finding a way to transfer it reliably from computer to computer. That’s not a problem today with ubiquitous Ethernet communications and TCP/IP stacks, but in the days of RS232 and RS485 serial communications, it was a very hard problem. If I send an ASCII ‘A’ over a serial line, binary code 0100 0001, there is a good chance that one or more of those bits is going to flip and the receiver will receive 0100 0101 (an ASCII ‘E’). The more characters you send, the worse your problem.

The other issue was forming messages. How do you send something like “Temp19 3” and have it properly understood? As humans, we can figure it out, but there is some ambiguity involved. It could mean that Temp1 is 93 and other permutations. This type of ambiguity led to the invention of XML. With XML, data is sent in tag–value pairs. Now “<Temp 19>3<\Temp 19>” is completely clear with no ambiguity. And if that gets sent inside of some packet within an error checking protocol, the message arrives safely and reliably.

Another way to encode an ASCII message is with JSON. JSON is a mechanism that is similar to XML but more compact and more integrated with advanced programming languages like JAVA. JSON data can be very easily moved into and out of JAVA data structures in JAVA code.

There are lots of protocols and lots of way to move ASCII messages. A very simple way is to use HTTP. HTTP is the universal mechanism for getting data from a web site. When you type a URL like www.amazon.com into your browser, you are actually sending an HTTP browse request to the server, which delivers the amazon.com main web page to you. Many programming environments are equipped with HTTP interfaces that make it easy for programmers to read and write (Get and Put in HTTP terms) HTTP data.

Unfortunately, most barcode readers, weigh scales, PLCs and other devices that have ASCII data don’t respond to HTTP requests. To solve that problem, our engineers at RTA just created an ASCII to HTTP gateway that can receive ASCII data and make it available to a programming environment over HTTP. A programmer can read the current ASCII data using an HTTP Get and send ASCII data to a device using an HTTP Put.

The 460AWI device moves ASCII data over HTTP. It’s simple, easy to use and fast to deploy – just the kind of product that we make at RTA. I think you’ll find that it fills gap in your factory floor tool set.