Real Time Automation 1-800-249-1612 Contact Real Time Automation Contact Us Real Time Automation Product Support Support    
  Real Time Automation Homepage Real Time Automation Products Technologies We Offer Industrial Library Company Information

OPC UA: Data Type vs. DataTypeDefinition

February 4th, 2014

Terminology is always a killer. It seems that we humans have to use special words among our own kind that only we understand. It’s pervasive. Every group of people, not just technologists, have words that they use that have special meaning and that only their own people, the people on the inside can understand what the hell they are talking about.

Sometimes this is funny. Last year I went to an INC 500 conference. It was really cool. Really fun. I met some people that are into building small business culture and those contacts have been really valuable to me.

Well after the conference I am talking to a young woman in her 20s and told her that I just came back from the INC conference. She goes “Wow – I didn’t think you would be into that stuff”. I was puzzled. What did she mean? Well we talked a bit and what she heard as “I N K”, like Tattoo Ink. She thought I spent a week in California hanging out with a group of people talking about getting Tats, doing Tats and equipment for Tats. Unfortunately, when she figured out we weren’t talking about the same thing I became very uncool, very fast.

I thought about this the other day when I was at the M2M conference where they were all talking about CIP. CIP trunking and all sorts of stuff related to CIP. Well, of course, I am thinking about the Common Industrial Protocol (CIP) of EtherNet/IP and DeviceNet fame but they, of course, were talking about something completely different. They were talking about “S I P” which I figured out was a technology in the telecom industry.

Then the next morning I am studying the OPC UA spec again – for the 200th time and I get real confused. It turns out that a UA Node has an Attribute called a DataType and a Reference to another node called a DataTypeDefinition. Of course, that confused me. You would think that the OPC UA DataType Attribute would be related somehow to the OPC UA DataTypeDefinition. No reason to have both right?

Well if you thought that, you’d be wrong. Very wrong. But it takes a few days of study to figure it out.

The DataType is the type of the value attribute in a Variable Type node. The type can be Boolean, UINT32, INT8 or one of many other predefined data types. What’s nice is that you can reference these types back to the OPC UA foundation where they are defined so that if two servers both use UINT32 there is no confusion as to which byte is the MSB and which is the LSB and that sort of thing. Each of those types is a predefined NodeID defined in a file on the UA website. And you can always make your own if you have some complex data type that doesn’t already exist.

So what’s the DataTypeDefinition (DTD)? It turns out that this is a Reference (pointer) to a type description which defines the node. Nodes are things like Folder Objects, Data Variables and many other standard objects and variables. The DTD tells you what the standard type is for an object so that a Client device knows what to expect in terms of Node structure. And just like the DataType above, you can create your own node structure and have it contain a whole bunch of nodes if that floats your boat in a particular application.

So, I guess the lesson is, CLARITY, CLARITY, CLARITY. Use simple, non-jargon so that your listener (or reader) can understand.

So that’s it for today. AAYF, ADBB and BBL!


(OK, for clarities sake. AAYF is Always Your Friend, ADBB is All Done Bye Bye and BBL is Be Back Later.)

Will DF/1 live forever?

January 31st, 2014

DF/1 is now entering middle age. I don’t know if there is anyone left who remembers its birth. If there is they would have to be in their 60s or 70s (Thank God I’m not that old). I’d bet they’d be retired by now. People of that era had a sweet pension deal at Allen-Bradley when it was still owned by the Bradley family.

But let’s stop and catch you all up before I go on.

DF/1 is one of those terms that a lot of people use but few really know. It’s used to talk about the protocol for moving data in and out of Allen-Bradley PLCs, some drives and a few other products.

In actuality it’s really just a link layer protocol. That means that its job is to move a message from point A to point B. Nothing more. Nothing less. It has absolutely nothing to do with the contents of the message. Just move it from here to there.

Where most people go wrong is that they assume that DF/1 also includes the messaging that allows a user to write a File (N7:200 or the like) and read a file. In actuality that messaging is something called PCCC which has a number of meanings. The meaning for PCCC that I like is Programmable Controller Command and Control language.

PCCC is the protocol that allows for reading and writing all the different kinds of file structures that you find in the various types of Allen-Bradley PLCs. PCCC is actually encapsulated in a DF/1 link layer message. So the two of them work together. A user application builds a PCCC message and then hands it off to the DF/1 layer who moves it from here, wherever that is, into the PLC.

At this late date, two thousand and fourteen, PCCC and DF/1 are still very much around and very much integral to the communications of Allen-Bradley PLCs. DF1 and PCCC are as important to the operation of RA PLCs as is EtherNet/IP, DeviceNet or anything else.

Why is that?

It’s reliable. The code is done. It’s already there and tested. There’s an infrastructure built around it that is comfortable and soothing. DF/1 and PCCC are kind of like those old slippers you have in the closet or that old work shirt you put on to putter around the garage. It just feels good.

I bring this up today because I had a conversation with a customer this morning about this. He’s got an old system that not only used DF/1 they modified how it works. Talk about creating a disaster for the future – that’s exactly what they did.

They need to take that old, modified DF/1 code that is generated by this old legacy system they don’t want to touch and convert the messages it sends out, the modified DF/1, into messages that a MicroLogix can understand, standard DF/1. Of course, they really mean PCCC but I didn’t tell them that. I let them call it DF/1.

It’s not a hard project. Just a day or so for us in the customers offices and we’ll do a gateway for them. We do a lot of these kind of “get me out of this jam” kinds of projects. It’s one of the things I really enjoy about the job.

So, to answer my original question. Will DF/1 ever die? The answer is an emphatic NO. There are probably 20 million Allen-Bradley PLCs in the world today. It will take another 75 years before they are all obsoleted and trashed. So, DF/1 (and PCCC) is going to be with us for a long, long time.

And that’s OK by me. It’s an old friend and I would miss it if it was gone.


Goodbye 2013

January 16th, 2014

2013 is in the rearview mirror. As I think back over 2013 I am reminded of the Dickens line from Tale of Two Cities, “It was the best of times, it was the worst of times…”.

2013 was another exceptional year for our company and our products. It exceeded the high expectations I had at the end of last year. It was an exceptional year in many ways for me personally. I was able to spend significant time in Italy, I received my Advanced Open Water Diving Certificate, ran a number of 5K races, learned a lot about measuring and building a culture in a business and discovered some new technologies that are going to impact Industrial Automation in the future.

But on the other side of the ledger, I had some people really disappoint me. I now think there are two tests of friendship. One, it has to stand the test of time. People come and go in your life but friends always remain friends. Until your friendship has withstood the ravages of time you probably don’t really have friendship. I have one or two friendships of over 35 years now.

The other important one is tempering. A friendship has to be tempered like iron. Tempering subjects a metal to stresses. The metal either survives and goes on to take its place as an important component in a larger structure or it’s discarded. It’s the same with friends. There needs to be something that stresses the relationship to make it a valued and important component of your life.

One of the most interesting things I learned in 2013 is that Ethernet in Automation is not king. He’s not even a prince yet. 73% of devices in an industrial automation environment are still Modbus, DeviceNet, Profibus and the rest. It isn’t anticipated that Ethernet enabled devices will be the majority of devices for at least another 15 years, maybe more. With all the focus that people like me have on Profinet IO, EtherNet/IP and Modbus TCP we sometimes lose track of what’s actually going on in the field.

And that’s serial communications using CAN and RS485. Which bodes very well for our Automation Device Converters as something needs to convert those serial channels to Ethernet.

That reminds me again that I have to try really hard to not let the forest get in the way and to really see the trees. I guess I am not that different.

Politicians do it. They focus on what’s going in “the beltway”. They’ll fight tooth and nail over stuff the people in the country really don’t care about. Most people don’t understand the Senate’s rules and couldn’t care less.

Corporate managers do it. They have a really hard time seeing the clouds on the horizon when sales are up and their bonuses are up even more. Most of the leaders at GM failed to see the need for smaller cars until it was too late though there is a lot of blame to go around there.

One of the things I am going to do in 2014 is to try to be more realistic and look for those trees in all kinds of forests. I hope you will stay tuned to see what I discover.


Thanksgiving 2013

November 27th, 2013

It’s Thanksgiving week. Very true,
I’ve found, that the older you get the faster the years go.

Thanksgiving is a great holiday.
No presents to buy for your wife or girlfriend. You can get by without seeing
the relatives. And, best of all, there’s about 12 hours of football. Can’t beat

One of these days I’m going to
watch that 12 hours of football in Turkey Texas, Turkey Creek Louisiana or
Turkey North Carolina. That would be kind of cool, to spend Turkey day in a
city named Turkey. More cool than the Macy’s parade. I’ve done that and
probably wouldn’t do it again.

Here’s a cool fact. Did you know
that a turkey is really part of the peacock family? It seems that good old
Chris Columbus who thought he was in India named the bird “tuka”, an Indian
name for the peacock. Six hundred years later and we’re still calling it a
Turkey. Doubt it would change now but I bet there’s a web petition someplace to
rename the thing.

And one more weird fact. In 1953
the purchasing manager at Swanson really screwed up. He bought an extra 253,000
lbs of Turkey! Either he added wrong (no computers then) or the Turkey farmers
put his kids through college. But to get rid of that 253,000 lbs of Turkey they
cut it up and packaged it on a tray with compartments for sweet potatoes,
dressing and peas. And thus, out of necessity, the TV dinner was born.

Despite this weirdness and all the
football, Thanksgiving is a good time for some reflection. It’s close to the
end of the year. Friday is a day that people like me (non-shoppers) stay home.
And no one even expects you to answer emails on Friday.

When I reflect I can truly say
that I’ve really been blessed the last three or four years. Too many too count
but here’s a few:

— Products have been very
successful in the market.
Modbus Slave
Devices connected to ControlLogix
;  Barcode Data
to Controllogix
Slave Devices connected to a BACnet Controller

and the countless other ones we’ve developed in the last few years. See more at
RTA Product Catalog.

— Great people to work with.
It’s a great team as you know if you have ever called our office. They’ve done
more for me than I can ever repay.

— Great friends that have supported me through the
difficult times in the last two years; Kevin, Bob, Erica, Kristen, Jeff,
Kristie, Stefanie and Sara.

— Teachers that have suddenly appeared to teach me things
that I needed to learn. Not always willingly. As my old friend, Tony Jorgensen
used to say, “They poured that bit of knowledge into me through my clenched

— Health. Isn’t that everything? I lost a bit of weight
this year. The key word being “bit”. (Truthfully it’s probably within the
margin of error on the bathroom scale). I managed to run 3 or 4 5K runs this
year. Feel like I am in pretty good shape.

— Books. I’ve obtained so much knowledge from the book
I’ve read. Improved myself in many ways. It’s a blessing to be able to read as
much as I do.

— Skill Development. Was able to learn more Italian this
year than ever before. Learned to Scuba Dive. Learned more about OPC UA and
other technologies that interest me.

— Writing Abilities. Found that I have some writing skill.
Wrote a book and one-half this year. Finished the OPC UA book and am now
writing another book.

— My Mom’s Health. She’s 91 and ½ and going strong. Pretty
independent and still able to make me dinner a few times a week. I’m lucky
enough to enjoy two grandchildren and my brother’s four quadruplets.  (That’s four children, not four sets of

— And, of course, some wonderful customers that have
worked with us through easy projects and some far more challenging. You guys
have treated us very well. I hope that we can continue to provide you with the
kinds of products and services that you have come to expect.

With honest and sincere appreciation for all these people
and wonderful things in my life, I truly wish each and every one of you a Happy


I Hate Cat’s

November 8th, 2013

I was thinking today about cats. Now, let it be known to all
here and beyond, that I really dislike cats. I think they are arrogant, selfish
and egotistical. If you’ve ever talked to one, you know that to be true.

But even though I dislike them, today I was thinking about
cats and why they have nine lives. Of course, I consulted Mr. Google and found
this rather interesting explanation:

One day, a very hungry cat entered
a house and found a plate of nine fish that were going to be eaten for dinner by
the nine starving children who lived there. The cat was feeling a little
selfish that day and ate up all of the fish in nine quick bites. With no food
on the table, the nine starving children died of hunger the very next day,
along with the cat who died from eating WAY too much. When the cat went up to
heaven and spoke with God, God was so angry with the cat that he threw him out
of heaven and made him fall for nine days all the way back to earth. To this
day, the cat still holds the nine lives of the starving children in his belly,
which is why he must die nine different times before he will stay dead.

Thinking of what else lives long lives made me think of “Grandpa
Modbus”. I call it Grandpa Modbus because it’s been around this industry since
before I ever walked on a plant floor and that goes back a ways now. In fact,
the project to develop Modbus began way back at Schneider Electric in the
middle 70s. That was the decade of Watergate, it’s when the Beatles broke up
and when Elvis died. And it’s when I was wearing an orange leisure suit (don’t
ask – the pic is gone forever).

In the midst of all that tragedy, especially the leisure
suit, Modbus was birthed. And it lives a long, long life with no signs of Alzheimer’s
or losing any steps. People are still using it today as much as ever but, I’ll
concede, some of that growth is from its preppy grandson Modbus TCP. By the way
if you’d like to learn about Modbus you can view the
award winning Modbus video.
Or you can read about
Modbus  RTU
or Ethernet Modbus TCP.

So what keeps this grandpa young and spry? Here’s what I

Easily understood data organization. Modbus data
is flat. Just a bunch of registers and coils. Non-programmers can easily
understand it.

A few simple commands. Modbus is simply command
response. A master sends this function code and the slave responds like this.
Almost anybody can understand it.

Very straightforward encoding. The way that the
commands and data are put on the wire is concise and uncomplicated.

And there’s more.

But what I’m really talking about here is simplicity. Like
everything else, simple always wins. Life is too complicated. Everything is too
complicated now days. From the cell phone to showers [I have a customer that is
adding web controlled Lights, Music, Vibrations and Temperature adjustments to
their offering.] All that is too much for me.

And because of it’s simplicity Modbus will always be out
there. That old man is going to live forever. And if you have Modbus in your
facility, here’s some products that will help you move it to your other

– this product makes a ControlLogix PLC look like a Modbus Slave to your Modbus
Master device.

– this product connects to a bunch of Modbus RTU Slave devices as a Master and
moves data from those devices into a ControlLogix PLC

460PSMM – this product does the same thing for a Profinet IO
network. Data from one or more Modbus slaves can be moved into a Profinet IO

That’s just a sample. There’s more if you look at our full line of Industrial
Automation Gateways






October 28th, 2013

I went to one of those new yogurt stores today. They are all
the rage now. You walk in, get a cup and have 5, 10, 15 different yogurts you
can get. Some are labeled “fat-free”. I find it interesting that the others
don’t say “fat added” or “lots of fat in this one” or “really tasty with all
the added fat”.

Once you’ve filled your cup with one of the fatty yogurts
then you have a bunch of different fruit you can put in. You have a huge
selection of nuts and then the toppings that all could just be labeled “sugar”.
In the end you end up with three times more yogurt, twice as much sugar as you
usually have in a week all for a price you’ll be ashamed to admit you paid at a

has a lot of options but not as many as the yogurt shop. You have to start with
Ethernet or Serial. Ethernet is, of course, a lot faster and a bit easier to
troubleshoot but it’s not a slam dunk that you want to use Ethernet for your
Modbus communications.

For one thing, the Modbus frame that travels inside
an Ethernet TCP packet
is the same size (about 220 bytes) as the frame for
a serial message. They didn’t change that frame one lick when moving from
serial to Ethernet.

And with Ethernet you need to get an expensive switch
involved. With serial you can just daisy chain all the devices together.
Devices with old 8-bit processors and a tiny bit of memory can easily do Modbus
serial but you’ll need a more expensive platform to do Ethernet. I really don’t
think there’s a cost savings there.

What about troubleshooting and configuration? It’s true that
with serial you have to set the serial baud rate, parity, data bits and parity
but with Ethernet you need to set an IP Address. And since DHCP isn’t really
used on the factory floor you have to find a way for the user to get an IP
Address into the device. I will give you that you can much more easily
troubleshoot Ethernet devices but other than that there isn’t much to recommend
Ethernet Modbus or Serial Modbus.

I can hear a bunch of readers out there screaming
“Throughput” or “Speed” or “100 Meg Networking” followed by “you moron”. Of
course, the Ethernet devices are going to be faster but the key is how fast do
you need to go.

I had a customer once with an injection molding machine that
dropped a new part every 6 seconds. Every SIX FREAKING SECONDS he would send
125 bytes of data back to his controller. He had that baby hooked up to a 1 Gig
Ethernet network when 150 baud serial would have been perfectly fine.

And it’s like that with a lot of Modbus devices. All these
level sensors, temperature sensors, energy meters and the like – none of them
really need to report data very fast. If you get data every few seconds It’s
almost always fine. Throughput is hardly a good reason to use RTU over

Now Modbus Serial isn’t a tea party – I’m not saying that.
You can have a lot of issues trying to get the RS485 network to work right. You
have to deal with wire termination issues, network termination issues and more
configuration issues than Ethernet devices.

But overall I still would take Modbus RTU Devices over
Modbus TCP. The simplicity of the devices, wiring and cost just favors Modbus

And if you want to move devices from other networks to
Modbus, the boys I’ve locked in the Engineering lab – they do get access to the
pool table once a day – have delivered a whole bunch of gateways that are
pretty impressive including.

They’ve built a bunch this impressive list of RTU Gateways:

Connect Modbus RTU
Slaves to a Modbus TCP/IP Client

Connect DeviceNet
Slaves to a Modbus RTU Master

Connect Modbus RTU
Slaves to a BACnet/IP Client

Connect a Modbus RTU
Master to an EtherNet/IP Scanner

Connect Modbus RTU
Slaves to a DeviceNet Master

Move Modbus TCP
Servers to a Modbus RTU Master

Connect Modbus RTU
Slaves to an Allen-Bradley PLC

Connect a Modbus RTU
Master to a BACnet/IP Client

Connect a Modbus RTU
Slaves to an ASCII Device

Modbus RTU Master to
a Modbus TCP/IP Client

Connect a Modbus RTU
Slaves to a TCP/IP Device

Modbus RTU Master to

Connect Modbus RTU
Slaves to BACnet MS/TP

Modbus RTU Master to
EtherNet/IP Adapter

Modbus RTU Slaves to
an Allen-Bradley PLC

Modbus RTU Master to
DeviceNet Master

Modbus RTU Slaves to
Modbus TCP/IP Server

Modbus RTU Master to
Ethernet TCP/IP

Modbus RTU Slaves to
EtherNet/IP Scanner

Modbus RTU Master to

Modbus RTU Slaves to
Profinet IO Controller

Modbus RTU Master to
Profinet IO Controller

Modbus RTU Slaves to
Profibus DP Master


And a similar list of TCP/IP Gateways:

Modbus TCP/IP Server to BACnet/IP Client

Modbus TCP/IP Client to ASCII

Modbus TCP/IP Server to EtherNet/IP Scanner

Modbus TCP/IP Client to ASCII Four Port

Modbus TCP/IP Server to Modbus RTU Master

Modbus TCP/IP Client to Modbus RTU Slave

Modbus TCP/IP Server to ASCII

Modbus TCP/IP Client to DeviceNet Slave

Modbus TCP/IP Server to ASCII Four Port

Modbus TCP/IP Client to Modbus RTU Master

Modbus TCP/IP Server to Allen-Bradley PLC

Modbus TCP/IP Client to BACnet/IP Client

Modbus TCP/IP Server to DeviceNet Master

Modbus TCP/IP Client to EtherNet/IP Adapter

Modbus TCP/IP Server to BACnet MS/TP Master

Modbus TCP/IP Client to Ethernet TCP/IP

Modbus TCP/IP Server to Modbus RTU Slave

Modbus TCP/IP Client to DeviceNet Master

Modbus TCP/IP Server to Profinet IO

Modbus TCP/IP Client to Allen-Bradley PLC

Modbus TCP/IP Client to EtherNet/IP Scanner

Modbus TCP/IP Client to Profinet IO


Give Drew a call on 262-439-4999 and he’d be glad to help
you figure out what you need for your specific application. Don’t call me –
I’ll be over at the Yogurt shop. Lot’s of “fat added” yogurts I haven’t tried


ASCII Revisited

October 25th, 2013

Had lunch with Chester the other day. Chester is an old
manufacturing guy from way back. And he’s got the scars to prove it.

Chester’s worked in papermaking, automotive, pharmaceuticals
and in a bunch of other industries. He’s pretty much been a hot shot PLC
programmer his whole life. I call him “jumper”. If he didn’t like his boss, the
management got stupid, the industry declined, whatever he was ready to jump.
He’d pack up his PLC doc and move on. That’s why he has so much experience in
so many industries.

Chester’s really a very simple guy and, like me, he hates a
lot of complexity. He thinks that most automation devices are way too
expensive, way too complex packing way too many features. Chester wants to open
a box, spend a ½ hour figuring out what he has to do and then do it. 200 Page
manuals, emails or calls to technical support, software tools that are needed
to manage the complexity really tick him off. You can tell when he’s ticked off
by the stack of cigarette butts in his ashtray (management seems to look the
other way on no smoking rule for Chester).

The simplicity of our ASCII gateway solutions is probably
why he thanked me again for our gateway that
moves ASCII
device data into a Rockwell PLC
(435NBX). This box is so easy to use and
works so well that customers just keep buying and buying it. Because all the
box does is to move ASCII data into a PLC there isn’t all that much to
configure. Chester just has to tell it how the serial data is terminated, what
baud rate it is and where to put it in the PLC. It just doesn’t get better than

This device is so popular because there are more than just
barcodes that have to be moved into a PLC. This box not only connects ASCII Scale,
Meter and Instrument data to a PLC but also lets the PLC write data out to
these ASCII devices. You can send a Marker string, for example, to a device
that does marking.

When we launched our other ASCII gateways, the one to move
ASCII data to Profibus Controllers,
ASCII data to Modbus
and ASCII data to Profinet IO and a bunch more (See the list at
ASCII Device Gateways), Chester practically jumped out of his chair. He’s now
working in an old line manufacturing plant with a lot of ancient equipment and
runs into ASCII RS232 and RS485 devices pretty often so this made him pretty
happy. In these old plants they always have a mixture of networks; some
Modbus, some DeviceNet, some Profibus – as the new lines
came in they added the latest and greatest. Now the latest and greatest is just
old and obsolete but it has to be supported anyway.

You may be asking “Isn’t 2013 and Isn’t ASCII data
obsolete”? Of course, the answer is yes but that doesn’t mean it’s going away.
There is legitimate need for it. It makes sense for some devices and will
probably always be around.

Same thing with my friend Chester. He’s old and obsolete but
he does fulfill some need and will probably always be around.

Siemens PLC’s

October 11th, 2013

I’m in Rome Italy tonight. Walked all over Rome today. My
hotel is near the Colliseum and I thought I’d just stroll around for a while.
Then decided that maybe I’d stroll towards the Vatican, get a cab along the way
and then take the tour. One thing led to another and before I knew it I had
walked all the way to the Vatican. Not sure how far I walked but it was a lot.
Enough to get several Calluses.

Sometimes you just end up doing things the hard way.
Occasionally there is no easy way so the hard way is actually the only way.

It’s like that when you want to read and write the data
table of Siemens PLCs. Know I’m no expert in the Siemens world. What I do know is
that arguably the best way to communicate with a Siemens PLC is to use Profinet

Profinet IO is an Ethernet communication protocol that
unlike a lot of other Ethernet protocols rides on top of IP and not TCP. That
means that the I/O messages of Profinet IO are embedded in an IP Layer message
and not in a TCP layer message.

Why is that? It’s done like that so that Profinet IO can get
I/O responses really fast. It eliminates all the TCP stack encoding and
decoding. But the downside is that you have to have those hooks deep in your OS
or TCP/IP stack to intercept these messages. I’ve written about that before. NO
reason to cover that ground again.

Went round and round with a customer on that the other day.
He is selling software and wants a binary that he can ship out to anybody that
will do Profinet IO Device Side communication. He’d really like to read the
data tables but can’t by doing I/O. Had a hard time convincing him that since
the I/O messages have to be intercepted deep in the OS you can’t easily just
send software out for different kinds of systems. I wish it was like that but
it’s just not possible with this technology.

With Profinet IO you’re going to be doing I/O communication.
I/O is OK but the contents of the I/O messages are fixed. You can’t really get
these ten variables now and then every 50msec get these other ten variables.
Stuff like that is really helpful in some applications. Instead you have to fix
the information you’re going to transfer. Or build another proprietary protocol
on top of Profinet IO.

What a lot of people don’t know about Profinet IO is that
there is an NRT (non real time) component to the Profinet IO frames. This can
be used in a number of different ways and is in there to allow diagnostics and
alarms to flow through from devices to controllers. What that isn’t though, is
a channel for a device to get access to the data table. If the end device runs
SNMP or can do XML then that channel serves to let those devices send that data
“alongside” the I/O messages.

EtherNet/IP has similar kind of functionality. In
EtherNet/IP CIP (Common Industrial Protocol) you have something called Explicit
Messaging. With Explicit Messages a Scanner device can send a message that
requests the Adapter device to execute a predefined standard (or vendor
defined) function code.

Now Siemens PLCs do have other ways to communicate that can
help you with reading and writing of Siemens PLC data tables. They have some
protocols that talk directly to the data table over an Ethernet comm link.

The protocols that can talk directly to the data table are better
in that you have much more control over the interaction. But I am wary of using
them. For one, I don’t know how well they are supported through the entire
product line. Will the next PLC they introduce support the same protocol? Or
because the data table is different, will it have somewhat different
functionality. Seems to me that there is some risk to using them. I’m sure that
some of you have used the things successfully. I’d be very interested in
getting your input and publishing your successes.

At RTA I chain my programming staff in the office for weeks
on end and don’t let them out until we get Profinet IO gateways. As usual they
responded well to my chair and whip management style. They built some really
cool products. Here are three of them:

– This device connects any ControlLogix, PLC5E, SLC
5/505 or Micrologix to a Profinet IO network.

– This device is a master to a network of Modbus RTU
Slave devices and combines those devices into what looks to the Profinet IO
Controller as a single Profinet IO device.

– This device is a master to a network of Modbus
TCP Slave devices and combines those devices into what looks to the Profinet IO
Controller as a single Profinet IO device.

So if you really want to move information in and out of a Siemens
PLC, Profinet IO is probably your best answer. But maybe there’s a better way.
Sheriff Carl is out there as are a number of really sharp Siemens PLC guys.
Maybe they can chime in and educate me on this one.

I’d appreciate it.



October 4th, 2013

I’m in the great city of Bologna today. This is probably my
favorite city in Italia. That’s probably shocking to people that have visited
Italy. Bologna not Rome? Not Florence? Not Venice? Have I lost my mind?

There’s very good reasons to like Bologna. For one, there’s
not a lot of Americans here. It’s not one of “THE” destinations in Italy. In
Rome, it’s hard to hear a language other than English especially in the summer
time. Secondly, the food is absolutely awesome. Bologna is in the plane of the
PO river, a great area for agriculture. Everything is fresh. And all delicious.
You can get Tagliatelle, Tortellini, Pasatelli and more. The only thing it’s
missing is the ocean. I’m as far away from water here as you can get in Italy.

One of reasons for me to come to Italy this week is to
attend the OPC UA Day – Italia. About 40 Italian companies showed up yesterday
to learn what UA is and how they can use it. Italy is a huge center for machine
builders and just like everyone else, they are under pressure to move data from
their machines to MES systems and other places. Claudio Fiorni, the R&D
Manager for Progea, is working hard to advance UA technology in Italy among these
machine builders.

The organizers did a good job detailing all the benefits of
UA including platform independence, scalability, security, a very advanced
mechanism for building data models and a lot more. They also announced a few
things I had never heard about, one of them being the capability to support
File Transfers. This new service is identical to FTP but doesn’t require you to
open an additional TCP port in the firewall. 
Plus UA now will support HTTPS and you will be able to use that security
layer instead of the one embedded in UA. Very cool enhancements.

Another interesting piece of information was more details on
all the different protocols that are going to drop their transport mechanisms
to use the OPC UA transport mechanism. Working groups in a number of different
industries have examined the UA standards and have realized that they can keep
their current object model and use the more secure, more reliable, more
flexible transport layers that UA provides. Efforts are being made all over the
world to encode these proven data models in the UA format. I am not surprised
to see the great momentum for this and that it continues to grow.

My takeaways from all this? Here’s what I think:

– Protocols like
Profinet IO,
EtherNet/IP and Modbus TCP will continue as
they are now. These are still the very best mechanisms from moving I/O data
from sensors into controllers. I don’t think any of that will change. RTA
products for
moving data from
EtherNet/IP, Profinet IO and Modbus TCP
to controllers will continue to be
needed in many different industries.

– Things like BACnet for Building Automation, 61850 for Substation Automation
and other protocols for the Smart Grid are going to adopt OPC UA as I described
above. It’s an easy decision. Drop the inflexible part the use now, the
transport layers, and keep the part, the information model, that they really

Like it or not the factory floor is going to be an extension of the Enterprise
IT system. A small part of it will be use those control protocols but more and
more everything will be Ethernet enabled and communicate using OPC UA for
configuration and non-control data.

What we are going to see in this new world is for the PLCs
to evolve into Service points. They will increasingly be called upon by other
devices to execute services. Essentially they are going to morph into some kind
of IT device with some control functionality. 
PLCs will be totally different in 5 years.

eXtensible Markup
Language (XML)
– The important of XML is growing day by day. The
information models for things like BACnet, 61850 and the Gas and Oil models
will be discoverable and available as XML schemas. XML is going to become one
of the most important factory floor technologies in the next few years.

There’s a lot more to say but there’s a bottle of Vino Rosso
and Passatelli in Brodo waiting for me.


August 26th, 2013

I’m in Tampa for a few days of scuba diving and touring the
area. I was able to dive the Crystal River north of Tampa for two days. It’s a
really cool place to learn to dive. There’s no current, it’s not very deep and
the water’s clear. In addition to all that you sometimes will run into a
Manatee or a Dolphin. And if you show up in November the river is loaded with
hundreds of Manatee’s. But that attracts a lot of tourists so there’s really no
peace and quiet in the water.

In the midst of that I worked in a few customer
teleconferences. Diagnostics was a very hot topic on yesterday’s call.
Specifically it was about our CAN protocols;
DeviceNet, J1939 and CANopen. The architecture of
all these protocols is the same. They are simply formatted application layer
protocols that ride inside CAN messages.

Think about TCP. EtherNet/IP Explicit messages ride inside a
TCP packet.
Profinet IO
acyclic messages
ride inside a TCP packet. Those protocols are just
specific ways to format the bytes inside a TCP message.

It’s almost exactly the same with CAN. DeviceNet, J1939 and
CANopen are ways of formatting the messages that ride inside of a CAN message.
The CAN controller chips which are now usually part of the silicon of the
microprocessor move CAN messages from place to place just like TCP messages are
moved around an Ethernet network. The controllers (Ethernet or CAN) know
nothing at all about what is in those messages, they just know to move them
from point A to point B.

And just like Ethernet, CAN messages have a CRC to verify
the validity of a message. A receiver knows that the message is valid because
the message doesn’t get received by the target node unless it is valid.

In CAN it’s even a little stronger than that. CAN messages
use a recessive bit to identify valid messages. A zero, the recessive bit, in
the ACK bit field indicates that devices on the network have validated the
message and found it to be valid. Any node that doesn’t think it is valid
writes a one, a dominant bit. No other node that thinks the message is valid
can override that dominant bit from the node that disqualified it.  IN a CAN network every valid message has to
be accepted by every node on the network to be valid.

I described this in our discussion yesterday and my customer
still didn’t think that was enough validation. I described how our entire line
gateway products (Modbus,
Ethernet, Profinet IO gateways)
all have diagnostics screens. And these
diagnostic data that can be accessed from any network. They can tell a target
node what nodes are online and what have failed, what nodes are online but
experiencing problems and so on. The RTA Gateways Diagnostics are pretty

They decided in the end to do a full loop check in addition
to all the diagnostic data available to both sides in an RTA gateway. With this
full loop check, a device that writes data through our gateway is going to be
able to read that value back to check that it was written. This is largely not
part of our gateway but has to be programmed at the application level by our customers

To implement full loop diagnostics like this, one side will
write a value. Our gateway will send that value on the other network. The
receiving device will accept that value, validate it as a valid application
layer value and then send it back to the original sender through the RTA

In mission critical systems like this, this
truly is the best way to make sure that a message is received by the target.
It’s just like diving. It’s mission critical that you don’t run out of air and
that you make a decompression stop if you dive below a
certain limit. That’s how you stay alive. And that’s how you make sure that
your mission critical applications stay online.

RTA, Inc. - The Industrial Networking Home for DeviceNet, EtherNet/IP, Ethernet Drive,
Modbus TCP, Modbus RTU, PROFINET CBA, PROFINET IO, BACnet, IEC 61131-3,
IEEE 1588, AS-Interface, PROFIBUS, EtherCAT and other networks.
© 2009 Real Time Automation, Inc.

Real Time Automation, Inc.
150 South Sunny Slope Road. Suite 130
Brookfield, WI 53005
© Real Time Automation, Inc. All Rights Reserved. |

(262) 439-4999 (V)
(262) 439-4989 (F)