Sign in to follow this  
Followers 0
Chris Elston

Allen Bradley's Devicenet verses Ethernet I/P installation

24 posts in this topic

If you are doing a new installation now with an Allen Bradley PLC, are you leaning more towards Ethernet I/P or is there still a large following out there in the North America wolrd for Devicenet based I/O installation on new projects? What do you guys think seems to be the "norm" now with Allen Bradley based installs?

Share this post


Link to post
Share on other sites
My vendor says that he is seeing the majority of installations going the Ethernet route. Edited by jackslater

Share this post


Link to post
Share on other sites
Our company looks at them from different perspectives. We use devicenet as a "device" bus off of the ControlLogix system to interface field equipment, "MCCs" ect... Use ethernet/ip to connect systems together.

Share this post


Link to post
Share on other sites
Ethernet IP here

Share this post


Link to post
Share on other sites
So do you put HMI's, Vision Systems and Robot controllers in the Ethernet I/P catergory or devicenet I/O bus?

Share this post


Link to post
Share on other sites
Devicenet is the network that sounds great in theory, but doesnt ever quite cut it. I know there are a lot of people out there that say once it's working its great, but wow what did it take to get you there. Let's not even talk about having to make a change in the system. Or if an electrician makes a small oops you may just be replacing the whole network. Kind of fragile for an industrial network. Ethernet I/P is so much easier to deal with. Buy the right switches and I dont see where you can get yourself in too much trouble. It's not really meant for the same type of installs, but I never really thought there was much cost benefit in dropping to the individual devices anyway. I like the idea of the devicenet MCC setup, but I have never had the chance to use one (except for one quick troubleshooting call). My only fear is going back to the device net sounds like a great idea mode - then you have to make it work.

Share this post


Link to post
Share on other sites
My customers are primarily specifying DeviceNet but we'll use EtherNet/IP given the choice because its easier to commission. However, in a standard product that we market, a Compactlogix processor does burst mode enet communication with a Fanuc Robot and I discovered what I believe are dropped packets every once in a great while. The data the robot got didn't exactly match the what the plc sent. Because they were move instructions (6-axis coordinates) to the robot, I put some additional integrity checks in by having the robot send the data back and ask the processor to verify it; no more funky robot moves or crashes. I've never run into that with DeviceNet or Profibus.

Share this post


Link to post
Share on other sites
As a robotic machine builder, we are seeing most everything go ethernet now. I think customers have had their fair share of devicenet, as well as us. Ethernet is something almost everyone can relate to and it doesn't have the bad rap that devicenet does. We have everything we can on ethernet; robots, drives, HMI's, I/O, etc.

Share this post


Link to post
Share on other sites
I suppose I'm a little cranky on this topic because I've fixed a lot of both networks that their owners just didn't put any reasonable amount of care into. DeviceNet doesn't deserve the bad rap it sometimes gets. I am dismayed by how many users will admit that they ignored some or all of the simple installation rules and then complained (some for years) about the reliability of DeviceNet. My field reports express surprise whenever I come across a power supply that's actually dedicated to the network. When the same kind of problems happen on Ethernet, they'll call in an "IT guy" to help out, or they'll start insisting that there's bad firmware in the end devices. For my money, complexity is the enemy of reliability. DeviceNet is simple. Ethernet is complex. I am happy when I see DeviceNet in MCCs. It's reliable, simple, and cheap. When I see EtherNet/IP in an I/O cabinet, I follow the cable from the 1756-ENBT down to the... oh, dammit.... usually unmanaged switch. Just like with DeviceNet, the designers knew from the very start that a managed switch was almost a necessity. But they choose to ignore it because it costs money. It's the same mentality and the questions are exactly the same format : "If it will work most of the time with XX, then why should I spend the time and money on YY " For DeviceNet: XX = cheap bulk power supply XX = unshielded cable tied to motor cables XX = no terminating resistors XX = no access points for diagnostic connections For EtherNet/IP: XX = an unmanaged switch XX = no diagnostic logic XX = consumer-grade wireless XX = no mirror ports for diagnostic connections The extra thing that gets me going is when customers say "I have never seen a problem mixing Ethernet and power". What they mean is, they've never seen a problem mixing Ethernet running office applications with 120V power at a handful of amperes. I agree that the tools that Rockwell has put into RSLogix 5000 to make EtherNet/IP devices integrate into the control system are far superior to the ones available for DeviceNet, and for that reason it remains much easier to configure EtherNet/IP products. If they'd do "premier integration" of DeviceNet into Logix 5000 so that you had parameter access and tag creation embedded into a single control and configuration platform, I think you'd see a resurgence in the popularity of cheap, reliable smart devices on CAN networks.

Share this post


Link to post
Share on other sites
Ken, I will give you if EVERYTHING is done correctly, then yes, devicenet will be the easy choice. HOWEVER, you and I and the rest of the world knows it will very rarely happen that way. Don't forget about the old "why can't we run this devicenet cable in with our 480? It has a shield." In a perfect world, devicenet works fine. In a real world, no devicenet is not the choice because of the problems. Not necessarly a devicenet issue like you said, but it is still getting a bad rap for it. Onto ethernet. In most plants I have been in, it is almost easier to get managed switches because you have a buyin from IT, which seems to help. It makes it more of a need instead of just a personal choice. Bottom line, unless every job is designed and built correctly, I do not see devicenet making a strong comeback. Beside that, I can change all my drive parameters very easy with ethernet via RsLogix5000.

Share this post


Link to post
Share on other sites
I agree with you here. I almost mentioned in another thread that you can actually stumble through the mappings of a scanner with CIP messaging, but it's kind of like writing something to replace RsLinx, by the time you figure your hours you are going to have more money in it then you can buy RsLinx for. The problem with this is if you do a "premier integration" of Devicenet into RsLogix 5000 then you will kill RsNetworx for Devicenet. Overall this may be good for Rockwell's sales with the resurgence of Devicenet, but I doubt those in charge of RsNetworx would like to see this happen. How many people actually buy RsNetworx for Ethernet? What I yearn for is the old Devicnet Manager. Something fairly crud that will allow you to map your network devices, even make it a little painful for non-Rockwell hardware, and nothing else. If you want to turn some bell or whistle on in your device that is not on by default you must use RsNetworx for Devicenet or some form of messaging to configure it. It would allow you to configure your slave mappings yet leave a market for RsNetworx for easily changing those advanced parameters. I know that RsNetworx for Devicenet will run on less than 5 nodes, but I can't say I have ever used Devicenet on an application with 5 nodes or less. Even my first application which only had traditional rack style I/O had 8 nodes. This would allow the SLC/Micrologix crowd to get back into networked I/O where there are very few alternatives

Share this post


Link to post
Share on other sites
I concur as well. I have installed many Devicenet systems, once it's up and running it seems to work flawlessly. I have even done a large Devicenet install with 48 VFD drives and nearly 500+ I/O drops on Devicenet no problems. HOWEVER, my topic is about what are you doing NOW, TODAY...When you sit down for the first time and drool over that million dollar automation project, what's going through your head. "this is going to be a cool project, ooohoo oohoo hoooo, I am going to use Ethernet I/P to tie it all together!"....... Obviously "devicenet" bashing may have an impact on your decision of one or the other, but it just seems too me, "US" meaning all of "US" decision makers here in MrPLC land seemed to be installing more Ethernet I/P than Devicenet now-a-days.

Share this post


Link to post
Share on other sites
Well I haven't eyed that million dollar automation project yet with TW Controls, maybe this coming year I don't think Devicenet is dead, but have not done a Devicenet application in almost 4 years. Part of it may be the scale of jobs that I do now. When you get into those million dollar projects it is very possible that I would do a mixed network as I have done before to use both network's advantages

Share this post


Link to post
Share on other sites
Ok, now I have to put my 2 cents in also (again). My disgust with device net has nothing to do with whether it is possible to make it work. Most of the experienced people here that I have seen post would be able to put together a device net app that, if left alone, will just plain work. The problem is when you are in a situation of an integrator or engineer. What you install is never left alone. Generally with device net, there are enough gotchas to make sure that any changes performed by someone with less experience will screw the system up. Sometimes it doesn't even take changes to the system, just someone doing troubleshooting. Twice I have had a plant electrician trying to track down a problem blow out a bunch of cards because - oops - you mean the 24VDC doesnt go there? Crap like that happens if it can. Anyone blown a bunch of ethernet cards similarly? It's had a shorter time to present problems, but I have not had any gotchas like that turn up with ethernetip. Maybe if device net had a specialized connector like the ends on an ethernet cable that would limit things. To some people, if there are terminals then the wires are meant to be messed with. I just dont think device net was well thought out as an industrial hardened system. Secondly is the install/setup time. I have never put together a device net system of any significance and not had to struggle through an issue or two to get everything working right. Maybe thats me, but I have never had that with ethernetip. Finally I have not seen it work in crazy installations - well maybe it did for a while. Usually when I see the crazy installations, I am on a service call and that is where the problem is. It's not like RIO or DH+ where the manual said this but just about anything would work. Now those systems would provide some head shakers... How in the heck??? Like I said before, the idea of device net is a wonderful one. Perhaps that is why I kept using it as long as I did. I finally realized that experience had shown that the idea was not reality. And yes Chris, if I had to sit down today with my million dollar project (maybe they are returning) I would choose distributed I/O with EthernetIP. Drives, weigh scales, etc on it also with minimal I/O in the plc cabinets. I might spend some time looking at control net if applicable, but I would try to give the owner a system with one network to maintain.

Share this post


Link to post
Share on other sites
We do have a million dollar+ machine on our floor we're building for a General Motors Casting plant right now and their specification is DeviceNet with Ethernet for programming and HMI. So for giggles, I'll keep track of the time it takes to get the 40+ nodes up and running. Nodes include a Fanuc Robot, a dozen or so 700s VFDs, and a bunch of 1794 flex i/o. I just wrapped up a 6 node Profibus machine and I gotta admit, the Profibus start-ups usually go smoother than the DeviceNet - both trumped by the Ethernet/IP. Edited by jstolaruk

Share this post


Link to post
Share on other sites
To answer your question without any personal input. In the robot stacking industry, our trend is ethernet last year, this year, and all the projects coming up are ethernet. We do however have one project that has both ethernet and devicenet. That is because we cannot get one device that is devicenet campatable. It is funny, that we will have that one device on devicenet and everything else on ethernet. Guess that tells where our company is going with the whole structure of things.

Share this post


Link to post
Share on other sites
Gee, how come no one has mentioned ControlNet? From what I've heard ControlNet is more robust than DeviceNet. Most of the new and existing installs I've worked on in the last five years (ish) has been with ControlNet. Scheduling is a bit of a pain, but once installed and set-up correctly can be very reliable...

Share this post


Link to post
Share on other sites
Really Controlnet? Wow, I have used controlenet in the past strickly for HMI communications. I am no expert by any means, and I am sure it was not a good application for it. It was an automotive mig welding line with 63 Fanuc robots, and 30 HMI's. Just the HMI's were controlnet and we had nothing but issues with it. We would loose communication all the time. Like I said, I am sure it was either setup wrong, or routed wrong, or something.

Share this post


Link to post
Share on other sites
There are two places where DeviceNet is most appropriate. First, Intellicenter MCC's. They come with Devicenet. It's all prewired. So you hit a Devicenet/Ethernet adapter and go on with life. Second, when you have a really long conveyor belt type system like a packaging or bottling line where the I/O density is very low and you can take advantage of the vampire tap system for attaching the devices. In some ways this is similar to the MCC example above. Outside of that, as soon as you get anything like a "medium" density I/O, or you have your I/O spread out over a very large area, forget it. Ethernet all the way.

Share this post


Link to post
Share on other sites
Ethernet/IP rules. I have looked at DeviceNet. We have even bought a DeviceNet development kit from Rockwell but we must put our effort into the higher bandwidth and through put systems. I can set up an Ethernet/IP system in no time. Sure the switches are more expensive but so is time. DeviceNet doesn't have the bandwidth that our customers want. How can one compare 100 Mbs to 500 Kbs?

Share this post


Link to post
Share on other sites
I agree, Devicenet in Intellicenter MCCs is the best option. According to AB, this can not be done with Ethernet/IP due to the noise from a 480VAC system. For everything else, go Ethernet/IP.

Share this post


Link to post
Share on other sites
While we generally do not get the million dollar job, we intergrate our systems into them. That said in the past year ALL of the requested specs that involved AB PLC's required Ethernet/IP. In fact one customer was convertering over to Ehternet/IP from Devicenet. I asked why the conversion and their answer is when it runs it runs...when it breaks it really breaks. One thing I do know. On the plant maintenance level techs seem a lot less intimitated by Ethernet/IP than Devicenet.

Share this post


Link to post
Share on other sites
By design when you get noise on ANY node in a DeviceNet network, it sends out a jamming packet and stops ALL traffic. This results in the eventual cryptic and useless "Bus Off" error that tells you everything and nothing. The only way to troubleshoot is divide and conquer. However, intermittent problems are even worse because usually the offending node is NOT the one that you identify as the culprit. There is a tool called a "Net Meter" which can help immensely in tracking down DeviceNet problems and even detecting some of them before they happen. However, even then, it's really tough to deal with. At best, you can put in repeaters in the network to break down the network into segments which at least helps. Hence all the comments point to the same thing...when DeviceNet works, it's really good. When you have a communication problem, it drives you up the wall trying to find it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0