Once up a time about 1995 I spent every morning at Burger King. No, I wasn’t enamored with the Croissan’wich or even the Double Croissan’wich [They’re really good by the way – I’d eat them every day if I wouldn’t outgrow my pants in the first 3 days]. No, I parked myself there with the large coffee and I studied the DeviceNet specification.

And I studied the DeviceNet spec. And I studied the DeviceNet spec some more. Probably for 3 months in a row I camped out there every morning. It got to the point where I could tell someone what page to find the Duplicate Mac State Machine or the I/O State Transition Table. Instead of knowing something really fun or widely applicable I became an expert in one of the most arcane and smallest niche technologies in the world.

This all came back to me last week when Richard in far away Australia asked me about the difference between UCMM enabled and Group 2 Only DeviceNet devices. Wow, “Haven’t thought about that for a while!” I said.

And it’s true. It’s something that we don’t often deal with anymore. When you build EtherNet/IP devices, you just support unconnected and connected messaging. It’s no big deal.

But it is a big deal for DeviceNet. DeviceNet is designed to support for small, cheap, slow, under-resourced kinds of devices. How sophisticated do you want your photo eye or proximity switch or valve? Not very. Small, cheap and slow works perfectly well in a lot of applications.

Well, not so fast. It’s hard to be small, cheap and slow if you have to process all the messages running around a 500K baud network. Slow is a huge problem when you have a network of 64 devices all of them transmitting every 5msecs or so. That’s a whole ton of messages coming into your communication port every few milliseconds.

To get around this problem, the DeviceNet architects created a connection type that allows the CAN Message Filters to eliminate all the messages coming from or going to any other DeviceNet node. When these filters are set properly, a device only sees those messages that are pertinent to it.

Devices that only receive these specific messages are labeled as Group 2 Only Server devices. These devices only support connected messaging and something called the Predefined Master/Slave Connection set.

That was a mouthful. Let’s take it in pieces. Connected messaging. That’s messaging where two devices agree to open a connection with the expectation of transferring some number of messages over some period of time.

The opposite of that is Unconnected Messaging. Unconnected Messaging is messaging in which there is no expectation of sending any more than a single request. Now, that request may be to open a connected connection but even that message is still a single request.

The software component that manages this connection is known as the Unconnected Message Manager (UCMM). It accepts messages to open and close connections, processes them and returns responses as required.

DeviceNet devices are either UCMM capable or UCMM incapable. UCMM capable devices are devices that can support the UCMM and can receive requests to open and close fully capable connections. UCMM incapable devices are devices that don’t support the UCMM but instead support something called the Predefined Master/Slave Connection set.

The Predefined Master/Slave Connection set (why is there no acronym for this?) specifies a group of messages that lost cost, very low resourced, slow devices can use to support DeviceNet. This connection set describes a minimum set of messages that can be used for all the basic functionality of a DeviceNet device; allocation of connections, duplicate MacID processing, and Explicit and I/O data transfer.

The messages of the Predefined Connection set are organized such that a low level CAN device can use it’s filter to filter out all messages except the ones that it really needs to process. Messages to open or close connections on other devices, other device I/O messages or UCMM messages are all blocked from the Group 2 Only Server processor. And that’s the beauty of this feature. Low level, low cost, slow processors can be used to implement these devices because they won’t have to process thousands and thousands of messages that are not pertinent to its operation.

UCMM capable devices on the other hand must provide that kind of processing. Every single message from every device on the network might be processed, at least on a limited basis, in a UCMM capable device [The DeviceNet software actually has ultimate control of the CAN filters and can choose to only close the filters to only receive a set of known messages from certain devices.]

UCMM devices are generally higher resourced, higher performance kind of devices. These devices are capable of supporting not only the Predefined Connection set but an almost limitless number of other types of connections with resources and bandwidth as the ultimate limiting factors.

UCMM devices can support multiple, simultaneous connections. UCMM devices can open up peer connections with other UCMM devices. There are a lot of possibilities that a UCMM makes available.

But here’s a word to the wise – none of that means much. Unless you are building a device where two of your own devices need to connect and transfer data there is not much other use for UCMM enabled devices. This is mostly because DeviceNet doesn’t define the application layer data transfer over these connections. So, you’ll never be able to just open a connection with some other DeviceNet device and transfer data.

The ONLY place I have ever seen this used effectively is in a “poor man’s” universal barcode scanner. In this application, four scanners surround an object each with an open connected connection to the other three scanners. First one to read a barcode sends a message to the three others telling them to stop scanning. Each barcode reader is a UCMM capable device and only, repeat only, functions in this way because it’s a single vendor’s equipment with that vendor defining the application layer message that shuts off scanning.

My advice – do it fast and simple, use the Predefined Master/Slave Connection set. There’s more to this but I have to go. I’m kind of hungry for a big cup of coffe and a Crossan’wich…

Every once in a while I use these pages to revisit the CIP Assembly. It’s really the most crucial aspect of a DeviceNet / EtherNet/IP / CompoNet / ControlNet object model. I’d venture to say other than the messaging modes, it is the number 1 key concept for CIP.

Object Models as we should all know are how CIP devices represent data. For those of us lucky enough (really?) to attend a Computer Science program it’s like old home week. At least in my day we heard all sorts of stuff about grouping data into some sort of object model. I don’t know (I could start every sentence that way) but I have heard that they don’t teach that sort of stuff in Comp Sci anymore. They just teach you to make applets for Iphones and crap like that. Suits me fine as it will keep my company in business for a long, long time if no one else knows how to write embedded software. But I digress (again).

Since I am digressing I just read a study that said women from the poorer parts of the world really like hunks – guys with that rugged masculine look. Women from more affluent places like the softer, gentler version, Man 2.0 I guess. (Drew tells me that studies say it based on birthconrol oil and the way the different hormones lvls affect choices) It was a blind study done over the Internet. I have more to say about that but back to our program…

Object models. CIP has its own way of representing data. It groups common data into objects. Every device has some identity data describing what it is; manufacturer, catalog number, description and so on. The Identify Object is part of the CIP Required Object set. There’s a number of these required objects; TCP Object, Router Object, DeviceNet Object and so on. Some of these are particular to one transport method (TCP Object implies CIP, DeviceNet Object implies DeviceNet) but all are required.

Application objects are optional. Most all devices have application data describing their real world I/O, things like Flow Rate and Flow Speed. These common data sets are also grouped into Objects. And if there are multiple of them, two sets of flows being monitored, you have Instances of that grouping; Instance 1 and Instance 2.

The data in these objects is referred to as attributes. Attributes have a name, a type, a value and other descriptors. The sum of all your Objects, Instances and Attributes is a CIP Object Model. And it’s the same for DeviceNet, EtherNet/IP and all the rest.

To facilitate the cyclic transfer of data, CIP has a special object, the Assembly Object. An assembly object has instances that are either Input instances (Target to Initiator) or Output Instances (Initiator to Target). That’s some of the formal language used in the spec but typically a PLC is the Initiator and a device is the Target.

The Input instances combine data from any number of application objects to form the data that is transferred to the Initiator. The Output instances describe how to divide the data that is received from the Initiator.

What many don’t understand is that you can have many Instances of the Assembly Object. You might have different Assembly Instances for different customer applications. Each Instance would support the particular data set that is important for that particular application.

For DeviceNet these choices are critical. DeviceNet cyclic data is limited to 8 bytes before the wildly unproductive and bandwidth hogging fragmented I/O messaging kicks in. Having different instances for different applications is very useful. With each different assembly instance supporting 8 bytes or less you can avoid paying the performance penalty for transferring data that isn’t important to this application.

Of course, that’s irrelevant for EtherNet/IP where you can have more than 400 bytes of EtherNet/IP cyclic data.

So there is my review of the Assembly Objects. Keep the cards and letters coming in. Until next time…

Every once in a while I get someone that just can’t understand why one EtherNet/IP node can’t talk to another EtherNet/IP node. It’s a common objection to CIP (Common Industrial Protocol) in general and EtherNet/IP in particular.

Why do they want to do that? Well, for lots of reasons. If one node detects a quality problem, other nodes may want to act on that. If a downstream impurity is high, there is no sense in injecting more expensive raw materials into the process. The best thing to do is to shut that injection process down.

CIP, EtherNet/IP, DeviceNet and the other protocols based on CIP are PLC-centric. That means that they are nearly always PLC based. Those systems have a PLC getting inputs from the network, processing logic and sending new outputs on the network.

Essentially, what these people are saying is that they want to eliminate the PLC. They don’t want to eliminate the logic – they still need the logic. They just want to move it farther down the automation architecture.

This is possible, even desirable in some applications. In fact, that’s what the CoDeSys Open Control Tool is designed to do. CoDeSys is an open PLC language that can be easily (within reason) ported to an embedded platform. You can then write logic for drives, valve controllers, IO blocks and anything else having the CoDeSys control engine.

OK, you do this and now you’ve eliminated the PLC. Great! Hooray – let’s all cheer. But now you’ve introduced a whole host of new problems. You need to keep track of all this low level code that’s distributed around the network, you need to have access to the I/O of the other nodes on the network – remember; you’ll need to make sure that outputs are only driven from one source. And how are you going to synchronize code that is running in 30 different processors.

Now, there is technology that addresses a lot of these problems. And there are people in universities and research labs that are trying out these solutions. Lucky for them, they have lots and lots of time and usually money to buy all sorts of stuff. But the short answer for the rest of us is to just use a PLC. Until there is a real easy way to address the backup, synchronization and management of distributed control we’ll just keep doing what we know works and has the least risk.

Appreciate your PLC more now? If so, just drop out to the production floor and give it a little hug…After all Valentines Day is nearly here.

I hear from lots of people that don’t really know anything about DeviceNet. They usually have some sort of automation product and a number of reasons why they need to add DeviceNet Networking. One of there first questions is “How do I learn this technology?”

Well there’s a number of ways. This is my short list:

1.      View my video on the 6.5 most important things to know about DeviceNet. Yes it’s 6 and 1/2. You’ll know why when you watch the video.  Learn DeviceNet

2.      Go to the ODVA web site and checkout their introduction to DeviceNet: http://www.odva.org/Home/ODVATECHNOLOGIES/DeviceNet/DeviceNetTechnologyOverview/tabid/72/Default.aspx. This isn’t bad but it is more sales-y than I would like.

3.      You could also visit my DeviceNet site and read my paper on DeviceNet. http://www.rtaautomation.com/devicenet/. This paper gives you all the important information you need to know about DeviceNet.

4.      There’s a lot of short intros to DeviceNet on the internet. Some of them are pretty good. Most of them focus on their product and not the technology. You’ll have to sort through a bunch of junk to get the information you need.

5.      You could do a web meeting with me. I have a 30 minute introduction to the technology, the RTA solution and the API. It’s really for people that are going to buy a stack to incorporate with their application.

6.      You could hire RTA to do training at your facility. Teaching is something I really enjoy doing. We have sections for engineers, for sales people or for technicians. I’ve done this overseas quite a bit.

7.      You could also read the specification. When you join the ODVA they’ll give you the spec (on CD). It’s pretty dry and boring and seemingly contradictory.

8.      The ODVA does four trainings in different parts of the country. You can get the current schedule from http://www.odva.org/.

When you are working with these resources, there are a couple of real important things that you need to understand:

1. DeviceNet is a protocol that runs on a CAN physical network.
2. DeviceNet organizes data in Objects. The individual data items are called attributes.
3. DeviceNet has two types of messages: Explicit and Implicit. Explicit is the one-time read and writes of specific data items. Implicit is the I/O messaging that happens continuously.
4. This object oriented data representation and the messaging are called CIP, the Common Industrial Protocol. CIP is also the guts of Componet, EtherNet/IP and ControlNet.
5. DeviceNet hardware is NOT cookie cutter. There are very real gotchas that will bite you in the butt if you don’t pay attention to the detail and talk to people who’ve done it before.

Learning DeviceNet is not hard if you concentrate on these key features while you sort through all the available resources. And call me if you have any specific questions. I’ll be glad to talk to you.

Is DeviceNet Still Relevant in 2010?

In case you missed it we’ve started not only a new year but a new decade. Think about all the changes since January, 2000.

I don’t think I had a cell phone ten years ago. I know I didn’t have an ipod. I had a cassette player in my car and this bulky set of tapes that used to get stuck in the cars cassette player. [At least I was beyond 8 Tracks – look it up on the internet if you don’t know what that is].

Ten years ago, DeviceNet was still relatively new.  It was introduced about 1995. Installations were just starting to roll it out in the late 90s. That pig, ControlNet, was in. 5 Meg and determinism. That was hot.

People said Ethernet wouldn’t make it. Way too expensive. Can’t daisy chain Ethernet they said and we have to daisy chain everything. No one, including me, could see how the prices for Ethernet switches would just melt away. Thank the lord our company never entered the switch business. I don’t need a product with 30¢ margins.

And no one could imagine the entire switch being integrated into Silicon so inexpensively that it can be part of a sensor. We’ve reached the day of daisy chained Ethernet. Wow!

So, it’s a new decade. Is the old guy, DeviceNet, still relevant? I’d argue yes but I’d qualify that a bit as you will see.

DeviceNet is built on CAN and CAN is really, really cheap. There are millions of devices that use CAN and the price of the silicon is next to nothing. In fact, it comes preloaded in almost every microprocessor you can find. All you need to do is to add a transceiver for about 60 cents and you have the hardware for DeviceNet. You’ll still need a small DeviceNet source code stack but that’s available fairly inexpensively. You can get either DeviceNet Master Source code or DeviceNet Slave Source code.

One thing about middle age is that all the kinks have been worked out. DeviceNet is now well understood. There’s tons of information on how to architect a network, figure out your power supply requirements and interface it to a higher level system. It’s now cookie cutter for a lot of installations.

Some might argue that DeviceNet is slow. That’s true but slow is relative. Most discrete processes really don’t need more speed than DeviceNet offers. 100, 250 and 500K baud are adequate for a lot of applications.

There’s also plenty of ways to move other data into DeviceNet with DeviceNet Converters and DeviceNet gateways. Those gateways make DeviceNet pretty flexible.

The only thing not going for it is that it isn’t Ethernet. Customers just love Ethernet because it’s all around them. They feel like they can handle it just as well as DeviceNet. But the costs are still going to be higher for Ethernet. There are currently not a lot of devices that are daisy chained Ethernet so switches (though cheap) still have to be bought, wired and maintained.

Yes, it’s a new decade, but I think we’ll see a lot of our graying, middle aged friend, DeviceNet.

Our customers never fail to astound me. There are some things that are so unbelievable that you never expect them to happen.

For my Dad’s generation it was men walking on the moon. He was born on a farm in Italy with no plumbing, electrical or anything else. I’ve visited the place. It’s like visiting the Flintstones. Everything is made of stone. Every successive generation added another stone room to this “house”. You can tell by the different kinds of stones (rocks) that they used and the different way they put them together. For him, the first bicycle he saw was a shock.

Something happened to me this week that wasn’t as dramatic as that but it still knocked me back. I had a customer that wanted to pass data between two Modbus Masters. We’re building about 40 different versions of our Device Converter Product line but I honestly never in my wildest imagination thought to put on the list a Modbus Master – Modbus Master Device Converter.

We’re building units to move data from DeviceNet slaves into MicroLogix PLCs. Units to move Modbus data to DeviceNet Masters and lots of solutions to move sensor data of all sorts to BACnet Clients. But Modbus-Modbus – I never thought anyone need that.

I should have known. If you build something and there is any gap in product line, that’s the first call you are going to get from a customer. How do they know?

Lucky for us, we can easily handle this request. Scott, our ace applications engineer will get it done in an afternoon or less. That’s the beauty of the 460 Device Converter line. It’s darned simple to make what ever converter our customers can dream up.

So, I officially give up planning. From now on, all we’re going to do is to listen to our customers and build Device Converters that they really need.

I’m sure that won’t be the end of this story. There’s somebody out there that’s going to reach for the phone to ask me if we can do something equally unique and unheard of. But that’s what makes the job interesting and keeps me answering the phone.

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.

Moving DeviceNet Data to a MicroLogix…Yes It’s Simple

No, this isn’t a torture device used at Guantonamo. And no, it’s not an image I created using my MAC (Truth be told I wouldn’t know how to turn a MAC on). It’s the 100^th Anniversary of the Swiss Army Knife. It’s a certified Guiness Book of World Records, largest Swiss Army Knife ever produced. 80 Tools. 110 different operations. 110 operations – that’s probably how many you’ll need if your kids leave it on the living room floor and you step on it!

Quite a device. If a guy was talented (let’s me out), you could build a shopping center with this knife. Just drop him on a desert island with this knife, come back 90 days later and you’d find a shopping center.

But if you look at it, it’s really pretty hard to use. It would probably take me about 10 minutes to find and isolate the right tool. I’d have ten puncture wounds from futtsing with all the other tools. Not my first choice for a tool. Hard to use, complicated with too many features.

On the other hand I give you the lowly butter knife:

What an incredible tool this is! It’s a combination screwdriver, hammer, box opener, paper weight and butter and jelly spreading device. It’s incredibly easy to use. Even if you use it upside down or invert it you can still get the job done.

That’s the point I was making today to one of our distributors. Our newest 460 product takes data from a series of DeviceNet devices and writes them into a Micrologix PLC. It takes data out of the Micrologix PLC and writes the data into those DeviceNet devices. And no, it doesn’t take 2 days, a 237 page manual, 4 calls to technical support and your lucky rabbits foot to make it work. It’s all web server based. Just link files in the PLC to the DeviceNet data for each slave. Less than 10 minutes to setup and check out. That’s why we say “The Hardest Part is Opening The Box”.

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…