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
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
AUTOMATION IT –
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.
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
of 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.
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
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
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…
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
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
Controller, 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
I guarantee it!
(I hope I don’t get kicked out of my own company after that
June 27th, 2013
If you’re ever in Maryland, I’d encourage you to find your
way to St. Michaels. It’s a 400 year old plus community just a hop skip and a
jump over the Chesapeake from Washington DC. St. Michaels is in what is called
the “The Hamptons on the Chesapeake”. It has all the accruements you expect of
small town Maryland; handsome churches, manicured colonial lawns, Victorian homes
and a pleasant southern culture.
But that’s not why I think you should visit.
I think you need to get there to see Dirty Dan’s [No Drew,
it’s not a place for your bachelor party]. You see Dirty Dan’s is a throwback
to something we’ve lost in a lot of places in America. Something that we’ve
been bred to not even miss anymore. Something that it seems only those of us
with wisdom, age and experience really appreciate.
I’m talking about Service. Real honest to goodness, take
care of the customer SERVICE.
Dirty Dan’s is a Service Station with actual service. No
mini-mart. No blaring commercials above the pump. Not even a bad cup of coffee
to be had much less a latte. The rotund Dan just pumps your gas, checks your
oil and the pressure in your tires just like he’s done for the last 34 years.
Dan had a sign up for a day or two; “GAS – No Coffee No
Kotex No Condoms” but the town made him take it down. It violated the
sensibilities of the ritzy, high end Maryland community.
We’ve lost almost all of that service spirit in America. We
now fix our own salads at salad bars [waiters use to bring salad carts
tableside to fix your salad for you], bus our own tables at restaurants, check
out our own groceries at the grocery store, print our own airplane tickets and
on and on and on. The American public has over the last 40 years been offered
poorer and poorer service and has become desensitized to it. We accept the lack
of service as “the way it is” and in the name of efficiency.
WELL TODAY I DECLARE WAR. I am going to the mattresses.
In the name of service!
Service has always been a top priority around here. One of
the things I always enjoyed was helping people solve problems. It always felt
good to help someone solve a thorny problem. One of the reasons that we have
always answered the phone live is that it provides better service to you guys
when you have problems, need to figure out how to move your data from X to Y or
just want to say thanks. We get a lot of that, by the way.
I’d like to think that I’ve passed on that commitment to
service to Kristin and Jessica who answer the phones, Drew who does inside sales
and Scott, Emily, and Carlos who provide support. They do a great job but today
I am taking it up another level. I just told our staff that I am creating the
RTA Customer Care Group whose sole job is to provide great service. The folks
in that area will be handling all the customer support issues and providing the
highly tailored device converters that have solved some really unique problems
for a lot of you.
THE MISSION OF THE RTA CUSTOMER CARE GROUP IS TO PROVIDE GREAT
So if you have an idea about how we can improve our service
to you, something more you think we should do or just a comment I’d like to
hear about it. But PLEASE, no emails that start off “Dear Dirty John”, it just
doesn’t sound as good as Dirty Dan. Sounds kind of creepy actually.
As always you can’t reach me on Facebook, Instant whatever
or Twitter. I’m available in all the standard ways; by email or leave a message
under the Contact us button or, better yet, by phone on
I’ll be looking forward to hearing from you. And yes, we’ll
answer the phone live when you call.
June 19th, 2013
KE SHOW JUNE 2013
It’s no secret that I like to talk. Some people say that I’m
a ham. Actually I like to write more than I like to talk but occasionally
getting up in front of a group of Control Engineers is kind of fun.
I had an opportunity to do just that a few weeks at the
Kendall Electric Network Expo in Grand Rapids. This was a huge event with about
300 attendees from all over Michigan. Rockwell did a bunch of presentations on the
basic tenets of EtherNet/IP
and general network infrastructure components. A few other companies did
product presentations – describing why their product is so incredibly slick.
I didn’t do that even though I have products that are worth
bragging about. For example, our 460ETCMM
easily connects a group of Modbus slave devices to a Rockwell PLC – yes,
any of them. That’s pretty cool. It has security, email, alarming, an automatic
mapping feature and a lot more. And there’s no Windows tool you need to keep
But I didn’t brag on it, though I could have… Instead I
focused on delivering a roundup of the way that people are moving data from the
PLC environment to the enterprise environment.
I started out by describing a couple of really interesting
Cisco projects that we will have 50 Billion
Internet devices by 2020. They’ll be collecting data on everything from soil to
space and lots more in between.
MES software is growing rapidly. 50% growth
projected over the next 4 years.
More tools to process the data.
More regulations and government “requests” for
data and information on our processes
So we have more data, more tools to process the data and
more demand for information than ever before. And a lot of that information is
in the PLC systems on the factory floor.
But how do we get that information to the Enterprise? I
covered a lot of the ways. Here’s few:
RSLinx™ – Rockwells premium product for
interfacing to PLC networks.
OPC – the traditional way of moving data from
factory floor systems into the PC environment where it can be mapped into
XML – ASCII based files that can be quickly and
easily transferred to many Enterprise programs. And since this generally goes
out more than comes in, you can do this very securely.
FTP – Transferring files around between the
Enterprise and the Factory Floor systems. FTP is great for things like recipes
but you usually need to map the data in a proprietary way.
The point of my talk was that all these kinds of things are
fine but none of them does the job the way it should be done. Too many times we
settle for putting an insecure, unreliable, unstable Windows PC in the factory floor environment to collect data and then send
it out another Ethernet port to some Enterprise computer. That’s just wrong on
so many levels.
What I told my audience was that OPC UA is going to change
all that. And if you don’t know what UA is yet, you really need to read my
book. It’s like $16 on Amazon. Here’s the link: http://www.amazon.com/OPC-UA-Overview-Embedded-Programming/dp/1482375885/ref=pd_sxp_f_pt
It’s a really easy read. There’s just enough information in
the book to whet your whistle on UA and get some of the technical papers that
have been done.
Be careful out there,
May 6th, 2013
I had an interesting phone conversation with a guy this morning on EtherNet/IP and how to use it. It’s very similar to a lot of the calls that I’ve taken over the years.
With EtherNet/IP, The first thing I always do is to define the terms so that we know we are talking about the same things. There is so much confusion about how the EtherNet/IP devices are labeled that I always have to clear that up first.
For the record, an EtherNet/IP Adapter which is also sometimes called an EtherNet/IP Slave or an EtherNet/IP Server, is the END DEVICE. That’s the device that is some kind of sensor or actuator. It is a valve block, drive or gateway like the Modbus TCP to EtherNet/IP device converter. The Adapter has the inputs and outputs.
The Scanner is the other end. That’s the controller side and it collects inputs from one or more Adapters, processes logic, sets outputs and transmits those outputs to the Adapters. Scanners are also known as Clients or even Masters. An Adapter is usually connected to just one Scanner.
Any device can be a Scanner. For example, you can send EtherNet/IP Adapter data to a Modbus RTU Master using a Modbus RTU to EtherNet/IP device converter. That device is an EtherNet/IP Scanner in a little black box.
So the guy this morning wants to build an application in VB and he wants to connect his application to a couple of Drives. All well and good. The problem right away is that he doesn’t want to spend a lot of money.
With EtherNet/IP it’s hard to avoid that. I usually give guys like him a couple of options. One, he can get an OPC Server and use standard Microsoft interfaces to access the drive data. That’s not always inexpensive and ties him to a MS environment. Many, many end users want as few MS devices on the factory floor as possible. There’s also some configuration hassles around OPC and training issues. OPC works well but there is an administrative cost to it.
A second option is to use a DLL. That’s not a bad approach. The interfaces are straightforward but the cost is similar to an OPC driver. You do avoid all that administrative hassle and issues with updates to Microsoft and people unintentionally screwing up the OPC driver (happens a lot).
But the question I always get to in the end is “Why EtherNet/IP?”. That kind of stuns them for a second. Aren’t I one of the EtherNet/IP gurus? Don’t I advocate it all the time on YouTube and in Blogs and in my talks? Yes, all true but that doesn’t mean it’s the be-all end-all.
The question I ask in simple systems like this is “Why don’t you just use Modbus TCP?” Modbus TCP is supported on lots and lots of drives. I am willing to bet that 95% of drives that support EtherNet/IP will support Modbus TCP. In simple systems, it is just as fast and just as easy to use. In fact, I would argue that writing speed references to a register in a Modbus TCP drive is easier than writing the assemblies of an EtherNet/IP drive.
It’s certainly cheaper and it can be embedded right in your VB code. It’s simple enough for most programmers to do on their own. If you don’t want to build it, it’s pretty inexpensive to buy and you might even find it for free. And you have zero administrative nightmares and can run it anywhere you can run your VB code.
The only time you really have to have EtherNet/IP is if you are in a RA environment and need to communicate with one of their PLCs or the device you are talking to gives you no other option.
In all other cases, it pays to investigate alternatives to EtherNet/IP.
April 26th, 2013
TCP/IP STACKS PART 3
In this blog I am going to discuss a little known flaw in a
lot of current EtherNet/IP
devices that causes problems for lots of EtherNet/IP Adapter device
When an EtherNet/IP controller opens an EtherNet/IP
connection it does that by first opening a TCP connection and then opening an
UDP I/O connection. The TCP connection is used to configure and instantiate the
I you’re and old timer, you’ll recognize that this is very
similar to what was done in DeviceNet. In DeviceNet we have Unconnected Message
connections. Those were special connections that did nothing more than instantiate
The problem that shows up in a lot of EtherNet/IP Adapter
devices is that the TCP connection is sometimes never closed. That’s okay if
the I/O connection continues to live. The controller is never going to use that
The problem occurs if the controller is disconnected.
Someone might power down the controller or pull the cable out of the Adapter,
the Controller or the switch. When that happens, the original TCP connection
remains alive. The I/O connection by specification must terminate due to a
timeout but there is no equivalent requirement for the TCP connection. It stays
alive and keeps any resources (RAM) that it had previously.
On a Controller power on or a reconnection, the Controller
opens a new TCP connection. The Adapter device allocates a new set of resources
to the TCP connection. That connection is used until the I/O connection is
instantiated and now you have two TCP connections.
If this happens again (a reconnection or controller power
cycle) – and remember this can takes months – eventually your Adapter device
runs out of resources. At that point, it refuses to connect to the controller
and you get “the call”.
Your customer says, it works fine for a couple of months but
eventually it locks up and I have to power cycle it. And you start tearing your
hair out over this intermittent problem.
One of the reasons we know about this bug is that it
happened to us on our Ethernet
Device Converters for ControlLogixs PLCs. We had
devices that worked fine for a while but eventually froze up. We traced it to
this very problem.
RTA is part of a working group at the ODVA that is making
the effort to incorporate some new technology into the EtherNet/IP specification
to resolve this problem. That effort will probably not get accepted until
sometime late in 2014 or even 2015.
In the meantime, contact us if you have this problem or want
to avoid it. We have some work arounds that we can give you to avoid that dreaded
intermittent failure of your EtherNet/IP device.
April 25th, 2013
TCP/IP Stacks are crucial to the operation of your EtherNet/IP, Profinet IO or Modbus TCP application. A stack that functions incorrectly is going to cause you substantial field problems. In the worst cases, it may give you intermittent problems and you know how difficult those are to solve.
AT RTA we have detected flaws in a number of stacks used in industrial applications. We’ve found problems stacks used my leading manufacutures. In cases where we have access to the vendors TCP/IP Stack source code, we just go ahead and fix the problems. But when we don’t, there is no easy resolution and if your device is dependent on that vendor, you are really at their mercy. We recently had a customer use Keil and a bug in their TCP/IP implementation cost our customer about 6 weeks.
Your best bet is to contact us before starting to design your EtherNet/IP Adapter, Modbus TCP Server or Profinet IO Device. We’ll let you know if we have identified any known flaws in that flavor of TCP/IP Stack. For some processors, we have found favorites that seem to work very well and we’ll be glad to let you know what stacks have been successful in other EtherNet/IP or Profinet IO projects.
For EtherNet/IP, there is an entire section of the ODVA specification that lists the TCP/IP Stack requirements. That specification details exactly what is required for minimal support for EtherNet/IP. You can get that from the ODVA or contact me and I will forward that section of the specification to you.
The requirements listed in that document are pretty basic:
· Internet Protocol (IP version 4) (RFC 791)
· User Datagram Protocol (UDP) (RFC 768)
· Transmission Control Protocol (TCP) (RFC 793)
· Address Resolution Protocol (ARP) (RFC 826)
· Internet Control Messaging Protocol (ICMP) (RFC 792)
· Internet Group Management Protocol (IGMP) (RFC 1112 & 2236)
· IEEE 802.3 (Ethernet) as defined in RFC 894
Essentially what that part of the specification says is that a device must support the IP, UDP, ARP and other protocols. The RFC is the Internet specification for that protocol. For example, RFC 826 describes exactly how the ARP (Address Resolution Protocol) must function.
That’s fine as far as it goes but it doesn’t really give you a mechanism to check your TCP/IP Stack against that specification. For the most part you are going to have to rely on your vendor to give you assurances that each of these protocols meets the relative TCP/IP Stack RFC.
But as always, your best is to always contact RTA to identify the best TCP/IP Stack for your EtherNet/IP or Profinet IO implementation.
I’ll look forward to hearing from you,
April 23rd, 2013
TCP STACKS – The Evil That Can Destroy Your EtherNet/IP Project
Note: This is Part 1 of two blogs on TCP/IP Stacks
I am often asked why RTA doesn’t supply our own TCP/IP stack. Many of our customers are developing EtherNet/IP applications and need a TCP/IP Stack for EtherNet/IP or a TCP/IP Stack for Modbus TCP or even a TCP/IP Stack for Profinet IO. That’s a fair question. Honest Answer: it’s really impractical and costly to do that. Let me explain.
A TCP/IP stack is the software that provides the basics of Ethernet operation. It is a suite of protocols and software that implement all the abbreviations we kick around every day; HTTP, TCP, UDP, PING and all the rest.
The TCP/IP Stack is the link between every single one of your applications including your web browser and email and the RJ45 plug in the back of your computer. It provides all the know how to make connections with other devices, route messages through an Ethernet network, packetize large streams of data and much more. The TCP/IP Stack is critical software not only for email and web browsing but for EtherNet/IP, Profinet IO and Modbus TCP.
At RTA we use uCoS and the TCP/IP stack inherent in it for all our Ethernet Gateways. For example, we have a box that moves data between a Modbus Client device like a Modicon PLC and Ethernet TCP. Both those protocols use the same uCoS TCP/IP stack to make the TCP/IP connection and transfer data.
If you think about this for a minute, you’ll see why a TCP/IP Stack is not directly adaptable from one piece of hardware to the next. The TCP/IP Stack has to understand exactly what kind of hardware you have in your computer and how to transfer a message back and forth to that hardware. At the lowest levels a TCP/IP Stack builds a message and then must send it bit by bit to an Ethernet MAC (Media Access Controller) after which it will be converted to electrical signals by a PHY (Physical Interface). This means that the TCP/IP Stack has to be really intimate with your hardware.
For that reason you can’t just pick up one TCP/IP Stack and reuse it for another device. It has to have the right drivers for that device.
There are companies that provide TCP/IP Stacks but most silicon vendors that incorporate MACs into their silicon provide a TCP/IP stack at no charge. For example, Freescale provides something called OPENTCP. OPENTCP knows how to address the MACs used in Freescale controllers but not controllers from other Silicon vendors like Phillips or Intel.
The problem for an outside vendor who would want to provide these stacks is to create all the drivers for all the different pieces of hardware. And then supporting new pieces of hardware. Of course, by Murphy’s law, you will never have a stack that is exactly what a customer needs. So, it’s a mess that I haven’t wanted to jump into.
But that’s not the end of the story. No way. The problem with the free stacks from people like Freescale and Keil and others is that they often don’t work quite right. They are usually close. But not many vendors in the Industrial Automation world like “close”. Perfect is usually their choice so at RTA we’ve fixed a lot of these free TCP/IP Stacks. When people order ANSI C EtherNet/IP Scanner source code or ANSI C EtherNet/IP Adapter Source code we can give them a working TCP/IP Stack for their controller.