Maybe its worth taking a step back and asking why devicenet? I personally think it is a poor networking option - cheap but poor. It is usually a royal pain to get working and to work around problems. I also would characterize the hardware associated with it as fragile when compared to other industrial networks. The good thing I can say about it is that usually once it is working it keeps working well.
I guess you might say I dont like it. Unfortunately I have worked with it enough that I get a fair number of calls just to troubleshoot device net networks.
so back to my step back. There are certain instances where I might still spec it as the best option (rare, rare, rare). What is your application?
I agree with PLCMentor. I've found it can be a pain to troubleshoot. You really have to stick to the rules that A-B lays out for DeviceNet.
We once had an outside contractor install some equipment and he didn't use a dedicate power supply. The power supply was also being used to feed PLC inputs via auxiliary switches inside some local motor disconnects (lockout devices). Those motors were completely separate from the DeviceNet network (except for the power supply, of course). Some of those switches got some moisture in them and all hell broke out in the DeviceNet network.
I'd rather use RIO when and if possible. The programming and mapping is almost identical, but the wiring is way simpler.
Ouch - yes you definitely need to have a dedicated class 2 power supply. And never, never, never let anybody wire anything hot on it. Did I mention fragile? Many a device net interface has been lost by electricians thinking that its ok - its just 24 volts.
I would suggest that ethernet i/p is the best and most sound networking architecture that ab has available. control net is ok, but you have to be very careful about your terminations and there are gotchas with that network also. Ethernet I/P is pretty straight forward and easy to terminate. I dont know of an ethernet I/P interface being destroyed by someone crossing some wires - may not work, but the interface still lives. Also good is profibus. It is associated with siemens and has a little learning curve, but it is a very solid networking solution with simple and forgiving wiring requirements. RIO is old and slow, but it is solid as a rock. Even if it is slow, it is generally faster than necessary for most I/O requirements. My only problem with it is that it is slowly but surely getting pushed out the door.
In my opinion the worst network is the GE Genius bus. Several years ago, we had several GE factory people in to give some training on new equipment. After the training I asked them to show us how to setup a Genius network. It took them three or four hours to get it working.
As an ex-Siemens employee, I was brainwashed into Profibus and when I worked as an integrator before that, my experiences with DeviceNet were less than stellar, so I would have to agree with the above sentiments on technical grounds. But from a practical standpoint, you are probably asking the question because DeviceNet has already been chosen for you or there is some overriding technical benefit, such as powering a device over the network, that demands that you use it. Assuming changing the network is off the table, my advice is to seek help in designing the network hardware and topology. My experience has been that 90% of the problems can be traced to the physical layer being incorrectly configured and implemented. DeviceNet DEMANDS that you be very careful about the physical layer design UP FRONT, because making changes on-the-fly has a tendency to cause multiple cascading problems that become more and more difficult to diagnose as they stack up on top of each other.
Probably the best resource I have come across on this issue was a workshop I recently attended put on by Molex (Molex bought Brad Harrison, who had bought SST). They make scanner cards, but more importantly they make connectors, cables, splitters, junctions, terminators and repeaters. They offer these workshops all over the country and if you can find one, jump on it. The do not sell specific products during the workshop, they spend all of the time promoting good layout practices and going over pitfalls to avoid, troubleshooting methods, design tricks etc. to optimize your project success. I wish I had known this before I had done the projects that vexed me in the past, I now know what I did wrong. If they are not doing one in your area, call them anyway, they are experts on topology and configuration. I'm not throwing stones at A-B (today), but I think they were too focused on the bit twiddling and not enough on the physical layer when we ran into problems. As I see it now, I think they look at the physical layer as just necessary add-on accessories to their overall goal of selling their electronics and software. They don't actually make the network hardware they sell (much of it is brand labeled from Molex), so their approach to solving problems tended to be throwing more of their stuff at it and not looking at things like trunk lengths, drop cable sizes, power supply insertions etc.
"If I had eight hours to chop down a tree, I'd spend six sharpening my axe." -- Abraham Lincoln
For the best use of Eng-Tips, please click here -> faq731-376
I agree the Devicenet physical installation including power supplies is important as with any communication network media.
I once worked on a project where the electricians tywrapped Cat5 ethernet cable to inverter leads to make the cable tray look neat - needless to say the system had mysterious problems.
In my experience with Devicenet, most of my issues were due to my own ignorance. After I got the network up and running it ran great.
The following document from Allen-Bradley discusses the installation of the Devicenet physical components in depth:
One comment on Ethernet/IP - it is still non-deterministic.
IMHO, unless the system topology is designed with "jitter" in mind and the packets are "scheduled" properly, process critical applications such as the front end of a polyester spinning plant and nuclear power plants should be looked at skeptically with respect to Ethernet/IP. See the following paper:
I'm trying to get my feet off the ground with Devicenet. In my spare time I have configured a vary simple network and am trying to get familiar with the steps required to get it up and running. and also make changes in addressing the I/O's.
Below is a list of hardware for my practice.
I guess what my challenge first is I have not found a basic setup on uploading and downloading procedures required to get this running the first try. What has happened is without the procedures I have just kept at it trial and error long enough to finally get it right and have been able to see my input and output on both the DNY and in the logix. can anybody give me some input on my below procedures.
First I open my simple Control logix file and go on line, then I open RSNetwork for Device net, Go online and Browse.
My project will show up with the proper nodes displayed from this point it starts to get a little cloudy. Like i said earlier I have not been able to find documentation for this procedure so far. Do I start out by uploading from the device to the project, any help would be appreciated When I do get it right I cant seem to duplicate the success on the second try not sure if I'm overlooking something.
Gonehunting,
Dont forget the termination resistors. It looks like you have a small network so your system may actually work without them so they are easy to overlook; however, the missing resistors will cause trials and tribulations down the road.
Thanks for the heads up PLCmentor I do have the resistors installed thanks.I have the devicenet covered and now am looking at implementing a panelview plus, does anybody know of any short cuts or crash course information that would step me through creating and configuring communications with a Panelview plus and Logix 5561. If I could find procedures for this panelview plus like the link amptramp helped me out with for devicnet, I believe it would help a great deal. so far i have not been able to find a compareable document/shortcut.
Gonehunting,
The panelview plus uses something Rockwell calls rslinx enterprise. The easiest way to setup your communications is to have a link to your processor on your development computer and use that to point to. I have been meaning to do some videos on this, but this work stuff keeps getting in the way...
When you open up your application, go all the way to the bottom (almost)of your explorer window and you should see RSLinx Enterprise. Expand that and click on communication setup. From there you can add a device shortcut and point to it on the right. There are two tabs on the right. Design and Runtime. If your access to the device is the same for your design computer as your runtime computer (recommended) then you can just click on the PLC you want to access and click the 'copy from design to runtime' button. when you create a tag in design, you will use the device shortcut you created as a prefix to your tags. checkout the help for the exact format or you can actually drill into your online or offline logix application to grab a tag that way. The design software gives you the capability to test your app so design a little and test - repeat. Every so often actually download to your hardware and test there. There are some differences as to how things will appear on the pv+ hardware.
