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

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.

How Can I Implement EtherNet/IP?

July 11th, 2013

I had an interesting call last week from a guy in Texas. I
love Texas. I love the food – best ribs I’ve ever had. I love the weather –
yeah it’s hot but I love it. And I love the sharply dressed women – won’t say
any more about that though I’d love to.

So, this Texas guy believes in doing pretty much everything
himself. He’s not a little guy either. He’s not one of those “All Hat – No
Herd” kind of guys. He’s the real deal. He’s independent and doesn’t want to
buy anything from anybody. He’s built his own PLC. Yeah, I know what you’re
thinking. So am I. Why in the world would you build your own PLC? Well, he has
kind of a strong hold on his market. They’re not going anywhere and the simple
answer is “he can”.

But now he needs EtherNet/IP and Profinet IO [He’s getting Modbus TCP from me and he’s
going to implement it but I haven’t told him that yet]. He’s a smart guy and
he’s looked into it and he knows that it’s just not practical to either build
it yourself or get one of the “free” ones. Building it is what his software
engineers recommend but they know they just don’t have 2-3 years to get it done
and get it right. It’s not Modbus after all. And since it’s not their first
rodeo (another Texas reference) they know that over time the free ones are
actually very expensive.

So, the insightful question he asked me is “How do I go
about this?” He wanted to know if a chip made sense, some kind of add on PCB,
software or a gateway. Excellent question. Something that a lot of my customers
have asked.

Let’s start with a gateway. We sell a lot of Industrial Automation Device
Converters and Gateways
. Why do people use a gateway? Usually because
there’s a low volume need to move data from one place to another. If you’ve got
data on
Modbus and you need it in a ControlLogix PLC
, then a gateway is an easy way
to fix that. You use that
Modbus to
ControlLogix gateway
because it’s quick to get, easy to install and not a
big investment in time or money. But he needs to do EtherNet/IP and Profinet IO
a lot. Adding a gateway isn’t a good architecture move for him.

Well, what about some kind of add on board or chip solution.
That’s not a bad choice. There’s a lot of those. The Hilscher NetX is one that
has always particularly impressed me. That kind of solution makes a lot of
sense if you have a processor that is tied up with some really intensive processing,
critically important or time sensitive algorithm and you don’t want to take a
chance screwing that up. In that case, you want to offload EtherNet/IP and
Profinet IO to another processor. But this guy doesn’t have that so I wouldn’t
recommend something like the NetX to him.

So, that leaves us with a software solution. We have royalty
free EtherNet/IP Adapter
, royalty
free EtherNet/IP Scanner
and royalty free
Profinet IO Device-side software
that he can put right in his processor.
It’s not very processor intensive software and EtherNet/IP doesn’t need much in
the way of flash or ram resources (Profinet IO needs a lot more). So, if you
have the flash and ram, this is really an excellent solution.

Now my friend with the large hat needs an EtherNet/IP
Scanner solution and I have that for him. What I don’t have for him is a
Profinet IO Controller-side solution. That’s really only available as a chip
solution or as an add-on board.

So in the end I recommended our EtherNet/IP Scanner and one
of the add-on hardware solutions to get the Profinet IO Controller

And I got him to agree that he would take me out
for Texas sized plate of ribs the next time I’m in Texas…

Profinet To Allen-Bradley PLC

July 8th, 2013

Many of you know that I have been educated as an Engineer. I
did the whole thing. Went to Engineering school, got a BSEE and graduated Cum

If you look up Cum Laude on Google (nobody uses the
dictionary anymore) it is a Latin term for “he spent too much time in the library
instead of at the Gym Bar chatting with young ladies from O’Donnell Hall”.
Yeah, I was the guy in the library every night practicing calculus problems. I
got a full 8 hours sleep almost every night. Still fell asleep in Chemistry
class but that wasn’t the lack of sleep.

So, I’m an Engineer, a software Engineer. And I’ve done some
really fine work. Not really any at RTA lately, I have people for that now, but
at Kimberly-Clark and Allen-Bradley. I got a lot of recognition there for my
software expertise.

But what I am going to tell you about today is really
amazing to me. It’s beyond anything I had hoped for. Our Engineers are
releasing a product this week for moving data from ControlLogix PLCs to
Profinet IO Controllers that just amazes me. They’ve done an incredible job
making something that is so functional and so adaptable and so easy to use that
I think this will be a real hit.

The product is our 464ETCPS. On the PLC side you will be able
to read and write any Tag in a ControlLogix or CompactLogix PLC. Or write any
file in a PLC5E, SLC5/05 or MicroLogix. That’s pretty cool.

The real interesting thing is what you can do on the
Profinet IO side. If you’ve been paying attention to me you know that all
Profinet IO Server devices look like I/O racks. They have a series of Slots for
Input and Output. In the real world, each slot is populated with a specific
type of module; 16 channel discrete input or maybe, 4 Channel Analog. Well,
that kind of organization follows here.

You configure the Profinet IO side by assigning data types
and data lengths to each of the 10 input slots and 10 output slots. So input
Slot 1 may be 4 items of Floating point data. Input Slot 2 may be 16 items of
Discrete input bits. And you do the same for each Output Slot.

Here’s the magic. You can then either manually assign all
your Tags (or files) from the Allen-Bradley side to the slots on the Profinet
IO Server side or let our Automatic mapping tool do it for you. If you have 10
Floating point tags they will end up in the first slot configured for Floating
point with unassigned Floating point items. When that slot fills, any remaining
floating point tags are assigned to the next slot configured for Floating

All of this is done easily and automatically for you. It’s
very IMPRESSIVE. If you need to move Tags from ControlLogix to a Profinet IO
, the 460ETCPS is going to be your best bet,
both functionally and economically.

Add in all the enhancements we’ve made to the product line
over the past year including email support, login security, diagnostics, data
translations, mapping enhancements and more and you are going to really like
this product.

I guarantee it!

(I hope I don’t get kicked out of my own company after that

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)