I write this in the car on the way to Illinois. Meeting with a Motion Control Distributor today.

I’ve brought Drew Baryenbruch, our marketing director, along with me on this trip. Drew is real smart about marketing industrial products but more than that he doesn’t mind driving. And I HATE to drive. It’s just such a waste of time, monotonous and frustrating. But I have to watch Drew pretty closely – he’s already taken one wrong turn.

The Motion guys were seeing today brought me an interesting application. They have some CANopen devices that are, of course, out of Europe. As is typical with European manufacturers they build in one of two protocols; Profibus DP or CANopen.

Profibus DP is a very impressive network. High speed, reliable, easy to use. But expensive. VERY expensive. Because it runs at 12Meg, it needs a low level ASIC and that ASIC isn’t cheap. The connectors are specially designed (no power on the bus) and very costly also. The biggest factor in using Profibus is that it’s easy to connect a Profibus DP device to a Siemens S7 PLC. If the application has an S7 – Profibus is usually the best choice.

CANopen is the other heavily used European sensor bus protocol. Were Profibus is almost exclusively used in Manufacturing applications, CANopen is used more in non-industrial and medical applications. You’ll find tons of CANopen in hospitals and medical devices. There are patient beds that use CANopen to send signals to all the motors around a bed.

CANopen is what our distributor friend here has. I had our super smart engineering staff come up with a board for them that adapts that CANopen connection on their device to Modbus TCP, EtherNet/IP and DeviceNet. That makes the device much more saleable in the US.

This is a pretty common occurrence for us. When we build  EtherNet/IP Circuit boards, DeviceNet Circuit boards and Modbus TCP circuit boards we customize the device for the target network. When you interrogate the device you get all the identify information that is specific to their company and the objects that are specific to their application. You can’t get that kind of device representation with an off-the-shelf interface module like Anybus.

Another common request for us is to meet some sort of hard, footprint requirement. For example, Aquasensors needed a very tiny footprint DeviceNet board. And as far as I know the board pictured here is the smallest DeviceNet board ever made.

Picture of aquasensor board with quarter

AS I always say: “RTA is the Burger King” of industrial automation development. You get it your way…guaranteed.

Johnr

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.

I get a lot of questions from customers about replacing RsLinx in their automation systems. It’s something that I have always wondered about. RsLinx is a good tool and provides a lot of functionality so why are these customers trying to eliminate it?

Well, for those of you that don’t know, what the heck is RsLinx? RsLinx is a software driver that knows all about talking to PLCs. Every PLC RA makes as a matter of fact. It can read and write registers in the PLC5s, SLCs, Logix and more. It is a communication server that can talk to any RA PLC that has an Ethernet interface. Sorry, for you PLC2 fans, you’re still out of luck [By the way, got a call today from an OEM that has hundreds of PLC2s and wants to keep them running – I’m going to build him a little interface box].

RsLinx has the PCCC drivers to talk to the PLC5 series, the SLC series and the MicroLogix. PCCC is the Programmable Controller Command and Control Language. It’s a binary protocol that implements the Read and Write command set that every RA PLC uses. RsLinx also has a little known, proprietary driver for the Logix series. That driver allows RsLinx to resolve tag names into an address and then pull data out of a PLC in a block read.

That’s the biggest difference between the way 3^rd party devices access RA Logix processors and how RA devices access Logix processors. 3^rd Party devices have to use the open CIP Data Service protocol standard to access the data tables of PLCs. The CIP Data Service protocol is open but not widely distributed. It’s on the RA website but you have to really hunt to find it.

The biggest drawback to the CIP Service is that you have to send the tag names to a Logix PLC to read and write data. That sucks big time! The packets going to the Logix processor are limited to 514 bytes and if you have 20 character string names plus 10 bytes of overhead per tag you can only get 10 to 15 tags in a message. Best case you are only going to get 30 or so messages through a second so your limited to less than 500 tags per second. That’s really slow for lots and lots of applications.

Though it doesn’t work very well for data intensive applications. If you just want to build your own solution with smaller data sets or you don’t have a critical time constraints, 3^rd party applications like the RTA EtherNet/IP Tag Client work really well. From your app you simply build a structure full of tags to read or write and send it to the Tag Client. It does a call back when your data is ready. That software is really handy for a lot of non-data intensive applications.

So, why don’t people want to use RsLinx? Mostly it’s price. If you have an application that is a dashboard, a vision system or something else; you have to include the RsLinx in every runtime. If you use something like our Tag Client to access a Logix processor, you avoid that runtime cost. As long as you don’t have thousands of tags to access or need millisecond response you’ve saved yourself a lot of money over the long run.

But what if you need that kind of response or if you have lots and lots of tags? Well I have some thoughts on that and I’ll share them in the next article.

I had one of those calls the other day. I’d actually love getting these out of the blue calls. You never know who they are, where they are or what they might say.

Most of the time these people are pretty capable and smart, sometimes they’re whack jobs.

One time a guy asked me if I could go to Malaysia. Well, I like to travel and don’t really know for sure where Malaysia is, so I said sure, I’ll go. If he thought I could help, who am I to deny him?

Then he tells me that I have to fly in on a helicopter. Oh – Oh. I am just terrified of helicopters. I have this perception that in a jet, we can just glide to a landing but in a helicopter I’m just gonna drop out of the sky. It turns out that I once, a long time ago, knew a dancer (ok, a stripper) that was a helicopter pilot. She assured me that they can “freewheel” or whatever the term is without an operating engine and land safely. In fact she practices that every week. I didn’t believe a lot of what she told me and I really didn’t want to experience a helicopter ride in which the pilot is going to turn the Engine off.

So the next thing out of his mouth is that the reason for the helicopter is that it’s too dangerous to go in on the ground. So, now I’m thinking that if I survive the crash, they’ll be a bunch of people who want to torture/eat/kill me. My rule of foreign business trips is to try to come back alive – you can’t tell a great story at a cocktail party if you’re dead. So, in the end I passed on the trip.

Anyway, the guy the called the other day asked me to tell him what the input and outputs were. “What inputs and what outputs?”, I said. He says he wants to implement his own embedded EtherNet/IP device and needs to know what the message in is and what the message out is.

After a few minutes of this it finally occurs to me that this guy thinks that EtherNet/IP is just some sort of Modbus messaging system. There’s a Master. The Master sends a message. The device responds to it. It’s no big deal.

Well I start to tell him about CIP object Models, Forward Opens, IGMP Multicasting, IO Messaging and all the rest but he doesn’t want to hear it. He just wants to know what  the GUZZINTOS and GUZZOUTTOS are. I tried to tell him that’s it a 6 or 8 inch specification of how all this works. That it took us almost 2 years to get it implemented and that we went through 2 years of field trials before we did this.

He was kind of shocked by that. But in the end, I really think he didn’t believe me. So I told him he could get the free version at the ODVA site. It’s not really up to date, there’s no one to tell you how to customize it for your device, how to build an object model with it or support you at the ODVA lab or when your product doesn’t work at a customer site.

Finally, he terminated the conversation. Probably to throw darts at my picture (which you can get at www.rtaautomation.com). Some folks just want to believe that life is simpler than it really is.

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.

Recently, I’ve had some interesting conversations with a developer in Texas about EtherNet/IP. They have customers that are requiring their I/O device to speak EtherNet/IP. This company doesn’t have much of a presence in the industrial market so EtherNet/IP is something completely foreign to them. Having EtherNet/IP means they can meet this customer’s requirement but might not add a lot of other product sales.

Naturally they want it to pay for itself through additional product sales. And their not sure they are going to get those sales. That presents quite a quandary for them as our software isn’t exactly cheap. In fact, I am very honest with everyone that our stuff is usually one of the most expensive solutions that they can find. 

Why is that? To provide the very best product we can and the very best service is expensive. We travel to all the ODVA meetings, all the SIG meetings and we often provide assistance for customers throughout the lifecycle of their product at no extra charge. We also provide tools, extra software modules that extend EtherNet/IP capabilities, test lab support and object model design assistance. Customers sometimes come here and camp out to learn what they need to know to make their product successful.

It is really true that you get what you pay for.  My friend John Mendocha was just telling me yesterday how his wife bought him new flashlights (Chinese made – very low price) and how within 24 hours both flashlights had broken.

So, what happened? Well, I encouraged this guy in Texas to get the free EtherNet/IP software. I couldn’t possibly discount our software enough and still provide him with the service he will need in the future. I told him that the free stuff presents a lot of risks, but short term, nothing is cheaper than free.

Some of the risks with the free stack are:

·       Designing an Object Model that makes sense when you don’t really understand what an EtherNet/IP Object Model is

·       Implementing your application objects without breaking the EtherNet/IP stack

·       Finding a device to test your EtherNet/IP device. If you use a ControlLogix you’ll be looking at $5K for the programming software plus RsNetworx.

·       Getting a listing of the last 100 hex messages sent to your device at the ODVA test lab and not knowing what the hell to do now

·       Having a problem at your first customer site where you device intermittently connects and disconnects and now knowing what to do

Essentially these are mid term and long term costs that pale in the face of the short term cost for a proven, reliable Royalty Free EtherNet/IP Source code stack, the tools you need to test it, the support you need to get it implemented correctly and having someone to call who’ll work with you when your customer is waiting for a response.

In the end, Mr. Texas decided that the short term cost for an “expensive” EtherNet/IP source code stack wasn’t really that expensive after all. It was really just a prudent business expense. And I think that was the right decision.

And now a blatantly commercial message: we have a royalty free Client and Server solutions for lots of platforms and operating systems including: Linux EtherNet/IP, Netburner EtherNet/IP, VxWorks EtherNet/IP and Freescale EtherNet/IP.

I promised in my last blog to give you the run down on the SPS show. Well, first there’s Nurnberg. Nurnberg is an old city that’s about an hour train ride north of Munich, which I think still counts as Southern Germany (Bavaria), though I could be wrong.

Nurnberg seems to be an odd place for this show. Northern Germany is the heart of German Industrial might. While Nurnberg is centrally located, it doesn’t have the manufacturers you would find in Stuttgart or Hannover. I’m glad the show is there though, as it doesn’t have the distractions of Munich and is much prettier than the northern German cities.

Here are my top takeaways from the show:

IT’S HUGE

The first thing about this show is that it is huge. There are twelve halls. Three I think are dedicated to anything and everything having to do with Motion Control. From Motors to systems, if you can’t find it at SPS, no one makes it. But the really weird thing is the shape of the halls. They’re not rectangles. Not even pentagons or octagons. One is a triangle with rounded corners. Another is sort of a rectangle with a ball on the end, and so on. Not only that, but it’s really hard to walk through them because the aisles go in all sorts of odd directions.

THE FOOD

If you like to eat, you’ll love this show. Vendors here aren’t into the logo’d up pen or luggage tag type of giveaways. Here, you eat (and drink). At the high end, the Siemens, Phoenix Contact, and Wago’s of the world have essentially complete restaurants in their booths. You can get sausage dinners or Wiener schnitzel with beer, wine, and cocktails. At the next level, you can get sandwiches, pretzels and some German bakery. At the lowest level, everyone has cookies and candy. Some companies were even handing out Schnapps and other liqueurs.

THE LANGUAGE BARRIER

Lots of attendees didn’t speak English. Maybe I’m an Anglophile but I pretty much believed that if you are an Engineer anywhere in the world you have a pretty good command of English. Well, that’s not the case. Lot’s of people moving through our booth were not English speakers. They recognized DeviceNet, EtherNet/IP, Modbus TCP but that’s about it.

WIRELESS

I didn’t see anywhere near the amount of wireless I expected. Maybe because I am working on wireless everyday now I am more sensitive to it, but it just wasn’t there. I’m not talking about the 803.11 Wireless Ethernet routers and gateways. Everybody has those - it’s old hat. But I barely saw any cellular, Zigbee or other sensor networking, even in the “wireless area” which wasn’t more than two small booths.

STUDENTS

Germans are big into Engineering education. There were many teachers taking students on tours, so a large portion of attendees were much younger than you would see in the US.

WOMEN

This is short. There weren’t any. Almost no women working in booths. A few companies used them to accessorize their booths but they were mostly the typical German style women (I won’t comment further). 98% of the wait staff doing food duty were women, but that was about it. Engineering is a very male dominated profession in the US, but in Germany it appears to be even more so. However, there was one very popular, nearly naked woman for some company in Hall 6 - I’ll post a picture if I get some requests.

EUROPE SALES BARRIERS

Distributor after distributor explained to me how hard it is to sell in Europe across country lines and even within a country. In Switzerland for example if you’re from Lucerne (German part) you have a really tough time selling in Geneva (French part). In France, you have to be French. In Belgium, Holland and other places it’s the same way. If you’re not like me, I don’t buy. I was totally unaware of this problem before the show.

It was a great show, our booth was a success and I am glad I got to experience it - sinus infection and all.

Yes, it’s my fault. I arrived home from SPS 2009 a week or so ago and I still haven’t recapped the show in my blog. I’ve got so much to say about it, but I brought home a pretty massive sinus infection from Germany that has kept me down and out until now. If you’ve been on a plane with any kind of congestion you know how miserable that was. I literally got home, walked into the house and collapsed on my bed without even taking off my coat. What I forgot to do was to take the phone off the hook. My “restful” sleep was interrupted by about 10 phone calls.

I actually developed my sinus infection right there in Nurnberg though not at the show. On Wednesday I decided that a good 20 to 25 minute run through the old town would be fun, so off I went. At home, you see, I run up and down “kettles”. For those of you who are not from Wisconsin – those are hills made by glaciers. I live in the midst of hundreds of them. When I run the next hill is always a short distance away. It’s agonizing but a really good workout.

In Nurnberg there are no hills. Just level ground with beautiful thousand year old castles and eight hundred year old restaurants. It was a fabulous morning run. Right up until I got lost. And I mean not just lost, but really lost. So there I am drenched with sweat, freezing in 40 degree weather, standing on a street corner in Germany trying to figure out if I go forward, backward, left, right or just stand there until someone comes along that will speak English. Well, 45 minutes later, I’m back at the hotel with my Sinus’ preparing for all out war with my head.

Sinus infections are the kind of thing that hit you hard, and keep you down for a while. I was able to answer a few emails but just didn’t have the energy to do much of anything else. Today, it’s a week later and I am just starting to get my old energy back. I even went for a bit of a run yesterday to prove I still had it in me.

Here are my top surprises of the show. I will go through them in detail in the next blog:

1. It’s HUGE – Eleven odd shaped halls with hundreds and hundreds of vendors
2. Their big into food. I’m talking full blown restaurants right there in their tradeshow booths.
3. A lot of Germans haven’t really mastered English – that was a surprise to me
4. Lot’s of Ethernet and not much CAN. In fact, a lot of EtherNet/IP – as much as Profinet IO, which surprised me.
5. Only a little wireless
6. Lot’s of students
7. Few Women
8. European Loyalty