Newsletter Issue # 20

Real Time Automation's - Best Darn Newsletter 

Beauty and Despair
XML and Its Weight Problem
Fun Facts and Trivia

Get a free RTA water bottle this month only!

Email your name and address to: jladd at by October 31st to claim your steal of the month.

Remote Comms
Simplicity vs. Flexibility OPC UA
It's all Perception
Botched Pitches and Business
Data Modeling in Industrial Automation



Practical tips and information for young engineers. This issue, featuring:

- Great Service: The Unfair Advantage Anyone Can Offer

- How to Pick the Perfect Barcode Scanner


Beauty and Despair

A Column of personal opinion by John Rinaldi, Founder and Owner of Real Time Automation.

I had yet another opportunity to visit Italy a few weeks ago. Instead of camping out in a single city, this time I functioned as a driver and tour guide to my cousin Elaine and her husband, George. It was their first trip to Italy and we drove through most of the country. We found amazing scenery, magnificent food, traffic nightmares, and delightful people. We marveled at the magnificent coastlines. We toured the biggest cities. We visited small mountain towns where we dined in the thousand year old homes of friends and family.

With all we saw, with all we experienced, Michael Angelo’s Pieta in St. Peter’s Basilica was the absolute highlight for me. I never tire of seeing that Madonna mournfully contemplating the dead body of her son. I marvel at the intricacy of the folds of her skirt, the detail in the ribs, the joints, the veins and the perfect fingers. The beauty in this piece is an emotional, moving experience no matter what level of spirituality you may have or what your belief system is. It brings so many emotions to the surface every time I see it.

It’s said that the 24 year old Michael Angelo selected his own marble, forged his own tools (a drill and a chisel) and completed this sculpture, one of the world’s most magnificent pieces of art, in only two years. That’s a lot of chipping, pounding, drilling and sanding in a very short time.

Italy is a country full of incongruencies It’s a country of unsurpassed vistas, a place with some of the greatest art treasures in the world and the most delicious food you can imagine. The Italian Engineers continue the superior craftsmanship of the ancient Italian artisans and produce some of the finest machinery in the world. And the people are emotional, loving, giving and as family oriented as any in the world.

But on the other hand, they’ve built a political and social structure that is collapsing and bringing pain, suffering and despair. The Italian courts are dysfunctional. It takes upwards of fifteen years to litigate contracts so the business climate is one based on relationships and tradition instead of innovation and entrepreneurship. The regulatory environment is one of the slowest and worst in the world. A recent story told of how a man from Milan just received the permits for a grocery store – thirty three years after submitting his application.

The labor market is so tightly regulated that it is lunacy to hire full time workers – once hired, they’re yours for life. The unemployment rate for young workers is more than 40%. Companies now hire new workers (young people) on temporary contracts lasting anywhere from a week to a year. There’s no permanency. No jobs that these young people can count on to build a life for themselves.

Older workers, employed before these regulations, enjoy the lengthy vacations, superior pensions and all the other benefits dictated by the government while their children are left to wonder if they’ll ever have a chance to build a life of their own. The marriage rate is declining, the birth rate is dropping and children in the 30s and 40s are living with their parents.

It’s a situation that I fear many in our country want to duplicate here; more and more regulations, a larger and larger safety net and more talk about dictating wages and benefits. Every single regulation or requirement, in isolation, seems proper and reasonable but the collection leads to the kind of despair and misery that I found being fostered on the people of Italy. I hope we’re smart enough to not let that happen here.




Trivia Challenge

· Orange and black are the colors of Halloween. What is each color associated with?

· What does the word "hallow" mean?

· Halloween candy sales average about how much annually in the United States?

· The common little brown bat of North America has the longest life span for a mammal its size. How long is its average life span?

· What famous magician died on October 31,1926?



Answers located on bottom of page.


XML and Its Weight Problem

I know. I’m playing with fire today. I am going to tell you why I don’t like XML and all the reasons it’s not a good way of transporting data on the factory floor.

XML has a weight problem, but then again, so do I. And just like XML, my weight problem is not because I can’t gain weight. I seem to be really good at that. I wish it were an Olympic sport because I’ve reached a point in my life where I gain weight listening to a Burger King commercial on the radio.

XML has a similar weight problem. It is overly complex, bandwidth and processing-expensive, and not easily integrated with a lot of today’s programming languages. I know this sounds like heresy, but my defense, as always, is the truth.

XML has been touted as THE solution for a long time now. And in the IT world, XML solved a very difficult problem that a lot of people struggled with for a long time. One of the biggest problems was, of course, byte ordering. On top of that, you had different standards for how the data was encoded. For example, some systems encoded Floating Point data one way, and others used a completely different format. There was no way to be sure how any data type was encoded, so everyone was writing very time-consuming and costly drivers to pass data from one system to another.

In the 1990s, with the rise of the Internet, this became a huge problem. It became impossible to code drivers fast enough for all the interfacing that needed to be done. A few innovators at Sun Microsystems led a group development effort to solve this problem, and XML was born.

XML is based on ASCII character transmission. Every computer in the world understands the ASCII character set. By transmitting data as ASCII characters in a well-defined format, you now had a universal way of moving data between any two systems.

Of course, XML is much more than that. XML is a document markup language that includes mechanisms to add attributes to data, structure parent-child relationships, define consistent names across applications, and much more. It is an almost-perfect solution to the data exchange problem in the IT world. And when you add the companion specifications to it like the Query Language, Style Sheets, Simple Object Access Protocol (SOAP) and the rest, you have a very powerful way of moving data between systems.

Unfortunately, all of that power comes with a price, and in Industrial Automation, the bill is as large as President Obama’s green fees and growing larger all the time. People like to disregard the deficiencies of XML by saying, “But you can send anything to anything because everything can parse XML.” That is true, but we’ve moved beyond that. Today, there are more and more requirements for moving data between systems. And not just log data, but sometimes some pretty high performance data. That data needs to be assimilated into the destination application quickly. XML kind of falls apart when you start talking about those things.

It’s expensive to encode and decode XML files. All that ASCII requires a lot of processing power to create, and lots of buffer space. It was easy to pay that price when it was just different IT systems moving data, but now that embedded systems for Industrial Automation are also moving a lot of data, that price just got heftier. Decoding and encoding XML and processing all those ASCII characters isn’t a problem for a big Windows server, but it’s really processor and memory-intensive for an embedded system. It’s a price that embedded system designers are unwilling to pay, and, luckily for us, there’s an alternative.

That alternative is JSON, and it 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 at State Software Inc. 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 the quick comparison between XML and JSON:

· Both are Open standards. XML is older and more established, but JSON is growing in popularity. JSON (in my opinion) is going to become the de facto standard for moving embedded data to server and browser applications.

· Both are interoperable. There are no systems that cannot support either data format.

· XML is a document markup language. The biggest difference between JSON and XML is in how data is structured. In XML, your data has to be mapped to the XML document structure. The receiver has to decode and map that data back to its internal structure. That not only takes time, it’s also inefficient. In JSON, data is structured as arrays and records, the standard way that data is structured in all programming languages. JSON is much closer to how data is normally structured.

· XML is really a document exchange language. It is really good at describing documents in an open, structured way. JSON is more of a data exchange language. It is much better at exchanging data between applications.

· JSON is simpler, requires fewer constructs, and in Java applications, is easier to implement than XML. JSON data files can be converted to Java Objects without using a parser.

Like XML, both JSON and XML use plain text that is self-describing and human-readable. Java files use the extension .json, while XML files use the extension .xml. Both have the ability to model parent-child kinds of relationships, and an http request can be used to retrieve a JSON or XML file. Both use a schema to communicate the structure of a data file. But there are also some things that are somewhat different.

JSON is more data-centric and less verbose than XML. Where XML uses start-tag / end-tag notation:


JSON uses name / value pairs:


Both communicate the same kind of information, but JSON’s notation is a bit simpler and easier to parse. Multiple name / value pairs are simply separated by commas:


Even multiple-object notation is simpler and more straightforward:

    {"firstName":"Kristi", "lastName":"Elativ"},
    {"firstName":"Emily", "lastName":"Draw"},
    {"firstName":"Megan", "lastName":"Snewo"}]

The beauty of JSON notation for Java programmers is that it can be easily captured by a Java program without being parsed like XML. There are standard constructs in the Java language that can natively capture this notation and store it in Java objects.

Like XML, JSON data can be requested from a web server using an HTTP request. This is one of the easiest ways of displaying data in a web browser and one of the most common uses of JSON.

You can expect that a lot more embedded applications on the factory floor will use JSON in the future as one of the mechanisms for exchanging data.

As for XML, at this point in its life, it’s not going to lose all the extra weight. (That makes two of us!)




Fun Facts

·Weird Al’s latest album “Mandatory Fun” debuted at #1 on the Billboard Hot 200 album chart, making it the first comedy album to ever debut at #1.

·The words written on Twitter every day would fill a book of 10 million pages.

·The average pencil writes 45,000 words or a 35-mile long line.

·A single bolt of lightning contains enough energy to cook 100,000 pieces of toast.

·The first text message ever sent said “Merry Christmas".

·The average person walks the equivalent of three times around the world in a lifetime.


  Trivia Answers: Orange is associated with the Fall harvest and black is associated with death and darkness; Sacred, holy or consecrated; About 2 billion dollars; 32 years; Harry Houdini
  RTA Website