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
developers.

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/O connection.

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
other connections.

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
TCP connection.

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.

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.

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 Laude.

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 up those hot chicks 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 at RTA lately but at Kimberly-Clark and Allen-Bradley. 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 point.

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 this product.

I guarantee it!

I’ve become jaded over the years. Sorry to say that but it’s true. I’ve lost faith in institutions, companies and people. I see them failing all over the place.

I won’t say anything about our federal government. If I started on that topics, this blog would be book length; maybe several book lengths long. I get more suspicious as I get older so I’m really suspicious now. [For example, any pretty lady that’s smiling at me – I immediately suspect she’s a “Lady of Negotiable Affections”, if you get my drift]

But I will comment on companies. How do these big companies make money anyway? Seems like they get a mass of momentum in the marketplace and it just keeps them rolling along no matter what their employees do to stop it. I remember one big gorilla in the Building automation industry. I offered the guy a way to save $10,000 on his project. He told me that it would be too much hassle to do it that way that I should just take the $10,000! I did. It was a Nice Vacation.

But back to today’s suspicions. Suspicions that were unfounded, I’ll let you know right off.

We have a DeviceNet interface in our gateway line that is a DeviceNet I/O Slave. So that means that it has an input assembly and an output assembly. A DeviceNet Master device writes to the output assembly, we get that process it and send it to another protocol like a Modbus Master which then distributes the data to up to 31 slaves. That’s all pretty straightforward and clear. Or at least it is to those of you familiar with DeviceNet and DeviceNet gateways.

Well, we now have the capability to manipulate data in the middle of the transfer. We can do math operations on the data as it is moved. That means we can do things like scaling. If we get a temperature that is Fahrenheit, you can enter the formula to convert it to Celsius when it is sent out the other protocol. That’s a really cool feature. A great add-on to the basic process of moving data from one place to another.

So, today I said to Scott, our lead product development engineer, “it would be really cool if we could identify pieces of data in a DeviceNet I/O block as Integers or floats and then manipulate those pieces and do math operations on them”. For example, if the customer could say that bytes 3-6 are a 32-bit floating point value and he could scale that to a value between zero and ten thousand.

Scott, tells me “we can do that”. I go what?  He insists we do that. So I make Scott prove it to me and, darn it, we really can pickoff data, do math operations on it and send it off to some other protocol.

I guess I’ll have to be less suspicious in the future.

There are some things that Rockwell does that make great sense, some that make sense to them when you look at it from a Rockwell Marketing perspective and some that don’t make sense at all. Today I’m going to talk about something in the middle; Ethernet communications for the SLC 5/05.  I don’t know how many SLC 5/05 users just don’t understand the Ethernet connectivity on that product but I’d guess it would be a lot.

A lot of people, too many in my opinion, look at that Ethernet port on the 5/05 and think “great – I can tie this into all sorts of things”. Of course, they’re wrong.

Let’s start by examining what Ethernet is. I say it all the time. You should think of it as a pipe. You should think of it as a link from one device to another. Just like my telephone links me to Kow Ming Yeh in Taiwan. Kow Ming and I went to grad school together about a million years ago. But just because I can call Kow Ming’s house in Taiwan that doesn’t mean I can communicate anything. I can call, get a connection but someone that doesn’t speak English answers we’re not going to accomplish anything. All I have is a connection.

So, at the minimum, the Ethernet port on the 5/05 gives you a connection. It just allows you to hook the pipes up between a device and the 5/05. So what travels in that pipe?

That is the key question. The 5/05 supports one protocol, something called PCCC which I think means Programmable Controller Command and Control language. PCCC is a very specific communications protocol that lets other devices read and write the registers of the 5/05. So, any device that wants to transfer information in or out of the data table of a 5/05 must use that protocol.

So, what can do that? Well, ControlLogix and CompactLogix PLCs can do that. RsLinx on a PC can do that and so can some HMIs. There is some non-Rockwell stuff that can do that but not much. We have a number of gateways that you can use to move data in and out of a 5/05 data table. Here’s some of the products that you can get that know how to use this port. If you want to

Move Barcodes into a SLC 5/05 – Our 435NBX is perfect for that. It just loads a set of registers with a barcode or other ASCII string every time a new one arrives.

Move Modbus RTU data in and out of a SLC 5/05 – Our 460ETCMM is a Modbus RTU Master that can connect up to 32 Modbus RTU devices to your 5/05. It links the Modbus Registers and Coils in those RTUs to the data table of the 5/05.

Move Profinet IO data in and out of a SLC 5/05 – Our 460ETCPS is a Profinet IO Device-side device that connects to a Siemens PLC. It allows you to connect the data table of a 5/05 to the I/O data on Profinet IO.

And we have lots more gateways for the SLC 5/05. The common thread among all these devices is that they have to be able to speak that PCCC messaging to transfer the data.

So why is that? Why did RA make this so hard? Well, I usually don’t defend them but in this case I will. In the first place you have to remember when this PLC line was designed. It was way back, long before open protocols. There wasn’t even the concept of open and there weren’t a lot of users or developers that had microprocessor based devices in those days. Most stuff was Discrete I/O based.

And why haven’t they updated it. Because they are eventually going to completely obsolete this line and adding more comms to it kind of defeats that purpose. It might not seem like it but they are doing the right thing.

But as long as you are going to be using these devices, our engineers at RTA will be working hard to make sure you have the right products and tools to keep these devices always be around to help you guys keep this stuff working into the future.

A week or two ago I went to the ODVA EtherNet/IP Developers Quick Start in Andover MA. It’s a really good event. Lots of good information in one place if you really want to drink from the firehose on EtherNet/IP.

After the morning presentations I was teasing Ray Romito of Rockwell about both his tenure at Rockwell (34 years) and the terms “Little Indian” and “Big Indian”. About the former I told him that he’s been at Rockwell longer than I’ve been alive! Not true but it was fun to say. I asked him what it was like to take a buggy ride with Lynne Bradley or party all night with Stan Allen. I expressed surprise why the company name wasn’t Allen-Bradley-Romito. The least he should have done was to marry one of their daughters.

For those of you who don’t know the terms Big Indian and Little Indian is a perversion of the actual terms; Little Endian and Big Endian. It refers to the order of data bytes within a processor’s memory. In the old days, Intel and Motorola had to decide that within a two byte word of data, would the most significant byte of the data be first or would the least significant byte of data be first? Well, Intel decided it one way and Motorola decided to do it the other way. There’s more lost productivity to this arbitrary decision than almost any other I can think of.

For those of you non-programmers, here’s why it’s important. The two hexadecimal bytes 01 02 refer to the decimal value 258 in a Motorola processor and 513 in an Intel processor. In the first case the decimal value is computed as 1 * 256 + 2. In the second case, it’s 2 * 256 + 1.

Ray knows all this and just made a slip of the tongue. I’m glad of it, of course. Always looking for something to tease somebody about.

But, as always, there’s a finer point. The finer point is that there are a lot of things like this that are second nature to us networking people and foreign concepts to everyone else. And that’s true in every industry. On my recent experience with serious biking enthusiasts (didn’t want to say nuts) I could hardly follow their conversations. Lots of technical gibberish about biking that I don’t know and really had no interest in.

We have lots of things like this with our industrial gateways. Besides endian, there’s different styles of Floating point that people use, there are weird parities like Space and Mark. And there’s all the strange ways of describing connections and making them sound important like Group 1 Only I/O Server. I’ve been using terms like Group 1 Only I/O Server in bars for a while now but have yet to find a woman that it impressed.

I have to hand it to my engineers, they’ve buried a lot of these details from customers so that you really don’t have to deal with it. All these weird terms and odd peculiarities are concealed in products like our ASCII to ControlLogix gateway, or our gateway to move Modbus registers to a BACnet IP Client or our gateway to move raw TCP data into a Modbus TCP PLC.

If you every get the opportunity to attend one of these events, please do. They’re pretty informative and fun; more so when the speaker routinely messes up the names of terms. If you do show up, I’ll be the guy out by the cookies giving him crap about it.

John

SIMPLICITY IN ALL THINGS

I’m a very simple guy. In many different ways.

I don’t want a cool car – I just want transportation. I don’t want fancy clothes – just keep me warm and comfortable. I don’t lie (or at least try hard not to) because I know I wouldn’t be very good at it. It’s too hard (complicated) to keep the story straight.

That attitude has carried over to RTA. Our products have to be simple. The one thing that I really know is that the Engineer deploying one of our gateways (http://www.rtaautomation.com/products/) is a very expensive resource to that company. If he has to spend two hours, let alone a half a day or a full day configuring our gateways then he just spent more money on labor than on that product. And that’s not right.

We’ve made a number of decisions to make sure that the deployment process is smooth and trouble free. And it starts with our web site. On our web site you’ll find a web page describing the product you need. If you want to move barcode data to a PLC (our 435NBX) then you’ll find that web page. If you want to move Modbus data to a BACnet/IP Controller (our 460MCBS) you’ll find that web page. And we’ve done the same with hundreds of other solutions. My goal is to make it easy for you to find the exact product that is going to solve your problem.

Once you’ve located the product, you can call and confirm your understanding of the unit and its operation. And you’ll get a LIVE PERSON to answer the phone. He or she will direct you to someone that can answer that particular question. Again, your time is important and we’re going to get you to someone that has the answers you need as fast as possible.

Next, I want you to get that Barcode to PLC gateway or other device deployed as fast as possible. Because we know what problem you have, we are going to preconfigure a lot of things for you. When you start the web server up, you are going to find just three or four steps you have to go through to get it all working.  And that’s where you will really save time (money, money, money).

A few months ago the RTA Engineers asked me to review the browser main screen. Now, you have to understand that I am the least controlling manager in the world. The people that work at RTA have the authority to do pretty much anything they want (short of increasing their own salary though a couple of them do have that option).  Anyway I hated the new main screen and tore it apart. This is probably the only time in the last few years that I played the “el president” card. I reserve that card for matters of great import where the customer experience is going to suffer.

So they redesigned it and its being deployed this month. I hope you’ll like the next screens. We’ve added some powerful new features but stayed true to the simplicity that you’ve come expect with our Modbus RTU gateways, BACnet IP gateways, EtherNet/IP gateways and all the rest.

I’ll look forward to hearing from you. I want you to hold us to a high standard of simplicity and ease-of-use. If this new look and feel doesn’t work right for you – let me know and we’ll do something about it.

That’s my promise,

John

Once upon a time I was a development engineer for Kimberly-Clark. That was a fun time in my life. Our group built registration control systems for their converting machines. Mostly feminine care products. We did the development in Neenah at the Corporate R&D and then deployed those systems at various plants in the US and Canada.

I liked that job a lot. The people were great. Neenah was a nice place to live. And I was learning a lot about automation and the difficulties you encounter deploying automation in a real world environment. Operations people are the same everywhere; the only thing that counts is how much that machine produced during the last shift. If you get in the way of that, there is trouble.

Those were the days that I first discovered CAN – Controller Area Networking. It was an amazing technology in the late 1980s. The speeds, 125K, 500K, 1M, were unbelievable alongside 9600 baud serial channels. Remember that at the time line speeds for the converting machine were really slow compared to today. Products moved down the line like glaciers. Today, KC makes 200 diapers every second. We made maybe 5 every second in the old days.

CAN was a breakthrough for a lot of reasons. Here are some of the advantages of CAN in those early days:

1.       Much less troublesome wiring. Daisy chaining 485 presents all sorts of problems. If you have just one loose wire or one bad device, nothing works and it is impossible to find. CAN is much easier to wire and much easier to troubleshoot.

2.       Power on the wire. That was a godsend. We could power sensors and some actuators without bringing power to them.

3.       Standard interfaces. In those days, the silicon for CAN wasn’t in our 8-bit microprocessors like it is today. We had standalone CAN MACs from Intel and others. Those guys all had standard interfaces that once we figured out could be used over and over again.

4.       Fast I/O movement – as I said before; massively faster than anything we were used to using.

5.       Much better troubleshooting – our micro got a signal if there was trouble sending data out. We never had that with serial.

6.       And best of all, maximum bamndwidth utilitization because of the unique way it does bus arbitration.

The list goes on and on. CAN for us in those old days was this very fast pipe that we could use to move lots of data (in 1980 terms) from one place to the next with little overhead.  At first we just stuffed our own data in a CAN packet. Later we came to understand the power of adding an application layer protocol on top of it to give us DeviceNet, CANopen, J1939 and all the rest of the CAN application layers.

Today, CAN is the basis for a lot of our gateways. We have DeviceNet gateways the move data between DeviceNet networks and Modbus (http://www.rtaautomation.com/products/460/mmds.html ), DeviceNet and EtherNet/IP (http://www.rtaautomation.com/products/460/esds.html) and DeviceNet to many other protocols. Soon we’ll have a bunch of CANopen gateways and J1939 gateways.

The world had changed a lot from my early days at KC. Now, I’m no  longer living at plants like the ones in New Milford, CT, Memphis, TN and Conway, AR. Instead I’m helping a lot of guys like you get more done, in less time with the easiest to use, fastest to deploy and best supported gateways in the automation industry.

I enjoyed my time at KC as a development engineer but I really love making you more productive.

John