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.

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.

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…