I’ve spent a bunch of time over the past month looking harder at the Profibus and Profinet IO Object Models than I ever have before. I think I’ve learned some interesting new facts and confirmed some of my earlier perceptions about those technologies.

One of the things I always said was that these technologies are complex. Siemens has done an incredible job of building protocols that are fast and functional. In fact, if you listen to Carl Henning at one of the Profinet IO seminars, Profinet IO will do everything any factory could ever need including making morning coffee. It’s hard to believe that they’ve built all that functionality into the technology.

But then you look at the size of the code and realize the downside of all that functionality. Five big megabytes plus a huge operating system like a VxWorks or WinCE. That’s a lot of physical resources you have to provide in your embedded device.

Besides size, another huge downside to the ultimate functionality and speed that Profibus and Profinet gives you is incredible complexity. The data representation for both protocols is complex as is the access to the data in a device from a Siemens PLC. Both protocols use a Rack / Slot / Point kind of data representation though in actuality that representation varies a lot from device to device.

The Rack Address is the first identifier of data. That part is pretty straightforward. In Profibus you have a 7-bit address 1-127 while in Profinet you have a TCP/IP address.

Next is the Slot address. All Profibus and Profinet IO devices are modeled as PLC I/O racks. The Slot address is the space in a rack where you can plug into a module.

Modules are another aspect of the data representation. Your device can specify that a slot has a specific module. For example, Slot 2 of your device can be an Analog Input module with four Analog input points, another aspect of the data representation. All four point AI modules are the same providing the identical IO data, diagnostics and analog conversion.

Points and channels are the lowest level of data representation where you identify the specific I/O point.

If all this sounds somewhat confusing and awkward, you’re right. It is! I don’t especially like it but that’s how it works.

If I was to contrast it with the CIP data representation I would say that the CIP representation is much simpler and more straight forward to explain. If I have a device with a combination of Analog and Discrete I/O it is much simpler to organize that I/O as Objects and Attributes instead of the more awkward Rack/Slot/Point representation.

Then there’s the issue of how the PLC accesses your Profibus or Profinet IO device data. Cyclic data is pretty easy. The data exchange with the PLC works just like CIP I/O data exchange. There is a buffer in the PLC that is sent out to the device and a buffer in the device that is transferred to the PLC.

There’s also a way to directly access data in your device from a PLC like a Siemens S7. In an S7 you can setup an instruction witch specifically addresses a Rack/Slot/Point within your device. It’s nearly exactly the same as the block used in a RA PLC to access a specific Object/Instance/Attribute in a CIP device.

It’s all a bit awkward but there are huge numbers of Profibus (and now Profinet IO) devices so it’s good to know.

I don’t know everything. In fact, I’ll admit I am in awe of a few people that seem to know everything. I was wondering the other day about the last person who did know everything known to man or at least western knowledge. It was probably someone in the 15^th Century. That’s when the printing press was invented and knowledge could be more easily disseminated.  There were so few books that an educated person could have read every one. It’s Hard to even read every copy of one thing today.

There are a number of things I just don’t get. In fact, I am ignorant about a lot of things. This is my annual display of just how ignorant I am by cataloging the current list.

 I just don’t understand:

1. Why was the EtherNet/IP Application Layer Protocol designed as a completely Master-Slave system? Why not provide a framework for slaves to send data to other slaves? All it provides is the connection but you can do that with any TCP device.
2. What’s the value of carrying Modbus packets in a CIP container? Who is going to use that? I don’t get that application at all.
3. What’s the difference between a Soft Starter and a Drive? They do much the same thing as I understand it. Why doesn’t everyone just use a drive?
4. Speaking of drives, why do they call it an inverter? Where did that come from? What’s being inverted?
5. Anything mechanical…nuff said.
6. Will PCs cost zero dollars in the future? Will you get one with a pack of gum? If you buy software, will they throw in a free PC? How low can it go?
7. Why is it so hard to buy things today? Yesterday I wanted to buy 2 Modbus devices, so I called StoneL. Got automated attendant. Then a woman who put me on hold twice and made me call the distributor 100 miles away from me. Automated attendant again. Then the live guy put me on hold twice because he couldn’t find my part. I had to ask three times for the price of the unit. Then he didn’t have delivery info. What an awful experience. I bought them from ASCON and had them shipped to me next day and paid half as much.
8. What’s the attraction to Lon? It is a novel technology. Yes, it does not need a controller. Everything can talk to everything but what is the advantage. You do want centralized control. Something that knows more than the local air duct knows to tell the air duct to open or close. Why is it so popular?
9. Can someone tell me if switches are going to be gone in ten years? Or five? Won’t every Ethernet device have a switch in it in a few years?
10. Are there two better, more capable, personable, smarter guys working anywhere together than Mike Bryant and Carl Henning at the PTO? They are the best I’ve seen anywhere in industrial automation.

So, that’s my quick list of things I don’t know mid year 2009. I stand ready to be enlightened. Let me know what you think.

There are the top ten questions I have answered lately. Let’s review them:

1. What do I need to connect to CANopen or DeviceNet?

To build any CAN device you need two things, a Media Access Controller (MAC) and a transceiver. The MAC is always silicon; either a standalone chip or a part of a microprocessor. The MAC unit handles access to the network. It decides when a bit can be transmitted over the network and manages error checking and things like inter-message delays. The Transceiver is the electrical interface. It converts the digital 1s and 0s to electrical signals on the bus. The transceiver is always a standalone chip in a CAN system.

1. Do I really need to have my EtherNet/IP product certified?

Yes. To get a vendor ID you have to sign an agreement with the ODVA (www.odva.org). The vendor ID is used to display the string name of the product vendor by configuration and diagnostic tools. One of the things the agreement specifies is that you agree to not sell any product that has not passed the ODVA certification tests.

1. What is the difference between an Ethernet Client and an Ethernet Server?

In an industrial system, a Client device makes connections with a number of server devices. Clients are typically devices like PLCs, HMIs and PC Systems. Servers are devices that wait for a Client connection. Servers exchange control and I/O data with a Client. Servers are devices like I/O blocks, Valve blocks, drives and other sensors.

1. How Can RTA’s Source Code Stacks work with so many different platforms?

When we built our CANopen, DeviceNet, EtherNet/IP, Modbus TCP and other source code stacks we built them for lots of different users in lots of different applications. We knew that some people would want to build systems around low end 8-bit controllers with no OS. Some would want to build systems using 32-bit systems with no OS. And others would want to build systems on high end processors with operating systems like Windows, Linux and VxWorks. To achieve that we implemented systems that used ANSI C, required nothing from the OS other than a 10-msec ticker and embedded all the interface code (CAN interface or Ethernet TCP/IP Stack) in a single C file. We built the system to support big endian or little endian and have absolutely no platform dependencies.

1. Where do I get EtherCAT source code?

This seems to be a common misunderstanding. EtherCAT is like Profibus, CAN and Profinet IRT. It requires a low level ASIC to handle all the network data exchanges. There is no source code. In fact, a processor is not always required. We’ve just implemented and EtherCAT system that uses a Freescale DZ to preprocess all the I/O and deliver it to the EtherCAT ASIC over SPI (Serial Peripheral Interface). Click EtherCAT Overview for my complete overview of EtherCAT.

1. Can I use BACnet IP to capture millisecond by millisecond power data?

No, BACnet is a request – response protocol. A Client device requests data from a Server device. The more data in the server, the more messages required and more time is required. With CSMA collision detection on busy subnets there is no way to predict when a message might be transmitted to collecting data with BACnet IP is difficult from multiple perspectives.

1. What is the difference between BACnet IP, BACnet Tunneling and BACnet MSTP?

The Tunneling version is a version of BACnet in which a device can send Ethernet messages without using a TCP/IP stack. The BACnet IP version is the one that uses Ethernet TCP messages to send and receive messages. The MSTP version is the RS485 version of BACnet. Click BACnet Overview for a complete description of BACnet.

1. How do I control how fast I send data to a PLC using EtherNet/IP?

The answer is that you don’t. A PLC is nearly always the Client in an EtherNet/IP network. When an EtherNet/IP Client creates a connection with a Server it indicates to the Server how often outputs will be transmitted to the Server and how often it expects the Server to transmit inputs to it. This timeframe is usually 10 or 20msecs but could be as low as 5msecs.

1. If I have a DeviceNet or EtherNet/IP device certified, when does it have to be recertified?

You really need to check with the ODVA but as I understand it, whenever you have a major new software release, you need to recertify. That means scheduling a retest and paying for another test. Unofficially, no one really does that. Instead, they buy the EtherNet/IP or DeviceNet Conformance test software tool and perform the retest themselves.

1. How often do you update your EtherNet/IP Source Code or DeviceNet source code?

In practice, almost never. The ODVA controls the specification and the specification only changes in the most dire of circumstances. Once you have a product that conforms to the specification there is no reason to make any upgrades or modifications. There is no new functionality. After all the years we have had this code there are rarely any bug fixes so updates to the source code are far and few in between.

You ever get tired of answering the same question over and over and over? Sometimes it seems that everyone has a question that they ask over and over. When I was growing up my Dad would ask why the more education I got the less intelligent I seemed. My wife would ask when are we going to buy fill-in-the-blank for the house.

The question I get from customers over and over again is “What’s A Client and What’s a Server again?” It’s maddening to me but a real need for them. The problem is that the terminology is different than IT terminology. A Client in a manufacturing system is a device that makes connections to a bunch of servers and starts a data exchange. PLCs are the typical Clients. Servers are everything else. All those devices that sit around waiting for a message from a Client asking to connect. Servers have one connection to one client. Clients have lot of connections to lots of servers.

While I’m on it can I complain about EtherNet/IP? Who came up with that? Everyone thinks it has something to do with the IP part of TCP/IP. And, of course, it’s hard to spell. I wish I knew how many times I’ve written it without the capital N.

Let’s not let ProfiNet off the hook. No, it’s not Profibus on Ethernet. The object model is similar but that’s where the similarity ends. Just Another stupid name that adds to the general confusion in the industry.

I can’t pick on the Germans but when they introduced Profinet that had all sorts of sub names for it. It was hilarious. There was Profinet RT, Profinet 2.0, Profinet CBA, Profinet IRT, Isochronous Profinet, Profinet Real Time, Profinet IO and probably a few more that I can’t remember. It took me a few months just to sort out all these names. It turns out that IO, RT, 2.0 are all the same thing. IRT really means isochronous. I’ll explain that sometime in the future.

Most industries have their own acronyms. The worst is NASA. I had a friend that did some work there once. [I worked there for 2 days once but after that incident in the I can’t go back]. My buddy told me that they actually give out a dictionary. He would sit in meetings and just keep looking up acronyms. Never really could follow the subject matter of the meetings as it was all one acronym after another.  We have our here for our employees learning industrial networking Industrial Automation Acronyms

We could talk about acronyms and stupid names forever but I’ll end this with a few of my favorites:

choke packet
No, it’s not the hold an irate IT Guy put on your Control Engineer last week. It describes a specialized packet that is used for flow control along a network.

color super-twist nematic
Is nematic even a word? If it is a word, what is it, and how does one super twist a nematic anyway? It’s actually something from Sharp Electronics usually referred to in its abbreviated form, CSTN.

Cuckoo Egg
I have no musical talent or appreciation. It’s just not in me so I actually didn’t know about this. If you download copy protected songs you might find a Cuckoo Egg. If you hear something other than the song; like a cuckoo clock sound effects you’ve found a Cuckoo Egg.  Cuckoo on you for not spending 99 cents and buying the CD in the first place!

GoogleWhack
This term actually has a couple of different meanings. In marketing circles it means a penalty that google imposes on your web site by ranking it really low. In search queries, a Googlewhack is a search quiery that produces just one result.

Send me your favorite acronyms – I’ll start a collection and post them. Later…

I don’t think that I’m crazy. Well, I usually don’t think it anyway but is the world getting crazier and crazier?

Hearing from lots of customers and they are telling me stories that make my hair curl. At least they would make my hair curl if I had hair. Maybe makeing my skin crawl is a better analogy.

Craziness #1. Customer number one has a messaging device. By messaging devices I mean those kinds of devices that send message packets as opposed to I/O. This particular customer has little presence in any networked-based automation application as they don’t have any networking capability. Sounded fine. That’s my best customer. RTA helps customers get networked-enabled. I gave him a very cost effective way to get EtherNet/IP and Modbus TCP enabled.

Here’s the craziness. Their management has decreed that they can’t spend any money. No investment at all. Nothing. Even if it expands the number of customers that might want their product. Just nuts to not expand your market when sales are down.

Craziness #2. This customer is a large manufacturing concern in Michigan. They’ve been around a long time and use VME extensively. Unfortunately, VME isn’t very popular any more. There are no spare parts and it is only a matter of time until this house of cards falls apart. But guess what? Management says we aren’t spending any money. That will last until the production line goes down. Then it will be a fire drill and I’ll get a bunch of extra money from them. OK with me.

Craziness #3. Another guy is telling me that he is going to use free EtherNet/IP, free Modbus TCP and as soon as he can find it, free Profinet IO. In the end it will cost him more than if he had bought everything from me. But no one will really know. His costs will be in travel, additional engineering labor, customer dissatisfaction and lost opportunities to do other projects. His accountants and management won’t be able to measure that cost. But he is getting that software for free…

Maybe it’s time for me to go a little crazy. I think I’ll run for Congress. Normal rules don’t apply and craziness is expected.

Please send your John Rinaldi for Congress donations to my office. Cash only. Unmarked bills.

Spending a few days over here in Merry Olde England! Besides drinking Strongbow and eating Pastys and Beef with Yorkshire pudding to my hearts content and my stomachs sorrow, I’ve met with some customers and talked about the direction that Ethernet seems to be taking. 

The only thing that’s not in doubt is that for systems using a Rockwell Logix processor (Control Logix or CompactLogix) the gig goes to EtherNet/IP. That the easiest one to integrate, it’s where there is the most support and the most available products. No brainer for that.

After that it gets mighty confusing. Profinet is just not taking off like we expected. My customer here in England reported to me that they had 3-4 customers a quarter calling about Profinet a year ago and NONE NOW! Yes, none. I suspect that device makers aren’t converting their huge line of Profibus products to Profinet. It’s just too darned expensive. Instead, they’re continuing to sell Profibus and using the Proxy to put the data on Profinet. It’s not a bad solution at all for the customer. The installed base of devices is on Profibus. You can link a whole bunch of Profibus networks through a Profinet link. 

Siemens continues to confuse the picture. I hear that all new processors are going IRT. If that’s true, why should anyone invest in Profinet IO? You’d be obsolete before you started.  

Another factor is all the companies like Softing and Hilscher and all the rest selling hardware solutions. I don’t have anything against them, in fact, I’d be glad to quote you on developing a solution for you; but no one really wants to add their ASICs to their boards. More space, more money and single source issues to resolve.

Oh and what is my customer hearing about from his customers; ETHERCAT! Maybe with the confusion that’s reigning in the Profinet market, people are saying the hell with Rockwell and Siemens, let’s choose EtherCat. Time will tell…

I get calls all day long from people who are confused about what Profinet is and what it isn’t. Here’s my top 10 list of the things I’ve heard over the last few weeks:

Misconception #10: Profinet Does Not Play Well With The Other Networks. No, not at all. In fact, Profinet integrates other networks better than any other network I know. It can easily accommodate DeviceNet devices, EtherNet/IP devices, Profibus devices and many others.

Misconception #9: The ERTEC Controller is Exclusively for Profinet IRT. No, not true at all. The ERTEC 200/400 can be used as a standard Ethernet switch.

Misconception #8: I Need to Have IEEE 1588 Time Synchronization to Use Profinet. No, not true. Both Profinet CBA and Profinet IO do not use the 1588 Time Synchronization.

Misconception #7: Profinet Doesn’t use Standard Switches. No, not true. Any Ethernet switch can be used to carry Profinet IO and Profinet CBA traffic.

Misconception #6: Profinet Is Incredibly Complex To Use. No, that’s not true for a user. If you know your data representation (how your data is represented to the network), it is not hard to connect a Profinet device to a Profinet network. Now, for the automation developer integrating Profinet into a device…well, that’s another story.

Misconception #5: Profinet Developers Have to Use an ASIC. That’s only true if you’re doing Profinet IRT. If you’re doing Profinet IO or CBA, there is source code available. There are lots of challenges to it but it is available.

Misconception #4: Profinet is only used in Europe. OK, that might be kind of true. A lot of Siemens PLCs are equipped with Profinet and Siemens dominates Europe. But we know that a lot of machines coming to the US from Europe with Siemens PLCs will have Profinet devices. And some US manufacturers are beginning to use Profinet as their base network so this may change over time.

Misconception #3: Profinet only works with Siemens Controllers. Sorry Sherlock, but that’s not true either. Profinet CBA for example doesn’t use a controller at all. True that most Profinet IO and IRT applications will use Siemens controllers but you’ll shortly see PLC from Rockwell and others that can scan Profinet IO.

Misconception #2: Profinet IO Requires special hardware – Lots of people think this because Profinet IRT requires an ASIC and there are a lot of vendors selling FPGA solutions. The truth is that if you have the source code both Profinet CBA and Profinet IO can run in any Ethernet processor that supports Ethernet without any special hardware.

And now the drum roll, please….The Number 1 Profinet Misconception is:

Misconception #1: Profinet is just Profibus on Ethernet. No, it isn’t. The truth is that the device representation is the same. Both Profibus and Profinet use network representations that rely on the Rack/Slot/Module kind of data representation. That means that all data has some sort of designation in that format but that’s where the similarity ends.