History, Advantages & Disadvantages of DeviceNet

I am trying to get a short history of DeviceNet.

Why I should consider DeviceNet network for I/O control of medium-sized assemble line with 200 inputs and 100 outputs.
They are concentrated in 6 clusters 25-50 feet apart.

The advantages of DeviceNet from the machine Builder's viewpoint and the end user's viewpoint.

Are there any disadvantages?

May I propose an alternative?

How about a big fat cable with 300 cores around 150mm (6 inches) round?

How does that sound?


If you want some real alternatives to Device Net then look up Profibus and ASi. Actually, you may find a Device Net/ASi combination even better than Device Net by itself.

Doug

I suppose I am qualified to talk about DeviceNet...I was probably the first person to sell a DeviceNet based system used on any significant process in Asia Pacific....about 1998 I think. The customer used it on a brand new meat processing plant.

The original system was conceived within Rockwell to achieve:

1. A low cost system that would allow simple I/O devices to have a network connection without adding too much purchase price to the device.

2. A system that had enough processing power in the nodes to handle RA's CIP protocol scheme, ie Producer/Consumer messaging, built-in Electronic Definitions, etc. The CIP protocol scheme is capable of using network bandwidth very efficiently. It also has enough horsepower to allow quite complex nodes to be effectively attached, eg, VSD's, Serial devices, Weigh Scales, RFID readers.

3. Nodes could be powered off the network. DNet supports up to 8 Amps in a segment...this is a lot more than say ASI bus.

4. The trunk/dropline scheme allows nodes to be attached and removed without taking down the whole network.

5. Electrically and physically robust enough to function reliably in adverse environments without extra costs.

6. Was conceived at the outset to be made an "open network".

At the time the system was designed the best choice to base the system on was the very commonly available CAN chip. Originally designed by Bosch for use in automotive applications, but the mid 90's over 7 major IC suppliers made miilions of them as a commodity item. Robust, low cost and well proven it was the best choice, plus the chips came in a range of capablities, ranging from bare-bones minimum, to quite powerful little processors.

Several other players also used the CAN chip, Honeywell created a SDS system and the Europeans created CANOpen. Often the same network device can be made to work on any one of these three, just by loading the correct firmware.

However DeviceNet is much more than just a physical media. The main innovation was the formation of ODVA (Open DeviceNet Vendors Organsisation) which has very succcessfully managed the system as a genuinely non-proprietary system. Most importantly they manage the specification layers that define the top layers of the OSI comms model, and they EDS (Electronic Definition Sheets) that ensure true interoperability of all DeviceNet products regardless of vendor.

Although the CAN chip is the main strength of DeviceNet, it also it's main weakness. It doesn't tolerate more than about 4 volts of common mode volt drop accross the network. For this reason it is VITAL to ensure that you plan the cabling correctly and ensure you have followed all the rules.

90% of all Dnet problems are one of two things, a cabling issue, or you haven't got the correct EDS file registered in RSNetworx. Get these things right and it almost certain the system will burst in to life and never give a moments trouble.

For the application you describe DNet looks like the correct choice. After many years of pricing these things I know that doing it the traditional hardwired method, and doing it in DNet will almost always work out within +/- 10% purchase cost....BUT the savings in installation and commissioning time will always be the winner.

Better still if there is always the possibility you can set up the entire network offline in your workshop and fully commission it BEFORE you go anywhere near the site...try that with hardwiring!!

If you are looking for a cheaper alternative for your Device Net I/O, have a good look at Wago. The I/O combinations are also more infinite.

You can get "dumb" or "intellegent" I/O combinations. Intellegent includes a processor you can program with ladder logic. This can take a lot of processing away from the main PLC processor, reducing scan times and allowing processing of I/O at the local level.

Further, they have comms modules at the local point to interrogate, for example, a power monitor on Modbus RTU. The information can then be gathered, scaled, processed locally and then placed on the Device Net line to the main processor.

Check at Wago Device Net

Seeing as how Bob is in advertising mode, may I also bring your attention to Rockwell's equivalent product, 1734 Point I/O.

1734 Point I/O

Similar concept, but significantly more reliable in our experience.

Seeing as how Bob is in advertising mode, may I also bring your attention to Rockwell's equivalent product, 1734 Point I/O.

1734 Point I/O

Similar concept, but significantly more reliable in our experience.

What controler you use? Some of the replies assumed AB but
I don't see it in original post. There are number of field
networks and DeviceNet is just one of them. All of them have
one goal - reduce wiring (or make distributed systems cheaper
simpler and easier for maintenance). Most brands support
more than one type (DeviceNet, ProfiBus, Remote I/O,
CC-Link, CompoBus/S, ...) and they all have different specs,
number of supported devices, price tags...

A few more thoughts:

1. Probably the key feature with DeviceNet is that it is a 100% open system, and is not tied to any one vendor. Indeed I have put together DNets with not one single AB component in them. The other key feature has nothing to do with the media, but with the far more powerful idea under the hood...CIP. Check this out:
http://www.ab.com/networks/CIPwhitepaper2.html

2. CompoBus/S is in fact Omron's in house version of DeviceNet. I am not sure why they went down this path of taking an open system and making a proprietary version of it, but hey it's a big world.

3. Profibus is well established mainly due to the sheer weight of Siemens presence globally. It uses an older far less efficient messaging scheme and largely relies on very high baud rates (12 M) to get adequate response times. By contrast Devicenet gets similar results trundling along at 125k, 250k, or 500k.

4.Also Profibus DP doesn't handle peer to peer messaging very well, so it isn't easy for example to set up say a PanelView and a VSD on the same network and have the PV act solely as a display for the drive, with NO PLC in the network. The upside of Profibus is that because everything is less flexible and more tied down, it is easier to get going if you can't be bothered reading the manuals.

5. Remote I/O is AB's older proprietary I/O network...not a contendor for anything new these days.

6. ASI is a neat system for pulling together simple I/O devices in a very low cost manner. It has the merit of simplicity and low cost, but for anything more complex it has limitations. As Doug suggested some people get around this by using DeviceNet as the backbone and ASI as a "dropline"...

If you are old enough to recall...all through the 80's and 90's the customers asked for "open networks", "vendors only lock us in with proprietary systems", "we want a single network standard"....and yet when RA devised a perfectly acceptable open network, and made the specification open and non-proprietary, the response has been less than stellar.

The fact is that you can have an open system that has all the features everybody wants, offers full interoperability with every product ...but requires the user to read the manual at least once...OR you can have relatively closed systems with fewer options and less flexibility that are easier to configure.

PS panicmode. I haven't assumed an AB processor anywhere in this thread...the original question asked for DeviceNet information explicitly, not a comparison with every other network out there. That is just far too big a topic for any post.

CompoBus/S is limted in I/O and application but is CHEAP compared to Device Net. Considerably cheaper in fact. Also only uses a twisted pair for comms. Use it on swimming pool centres for remote control and indication panels and alarm panels. Works very well. Has the advantage over ASI that it is quite happy with analogue I/O. Always getting screwed on price.

Have used Device Net with AB and Omron processors. May get to use with Hitachi shortly, if I win the job. Have used a variety of I/O including Omron, AB, serial devices, Wago and many AB Powermonitor 3000s. Works really well.

I like the advent of type 2 Device Net devices with lots of maintenance information built in. For example, number of operations of each output, etc etc. Can be shown on a screen to assist maintenence staff when assessing, for example, a relay may be approaching the end of design life. As mentioned by PhillipW, one has to watch common mode volt drop across the network like a hawk.

ASI has some fairly severe limtations with respect to I/O numbers and types. It is a very good, and cheap, digital I/O network and very well suited to machine control.

Profibus is liked by many due to the possible length of the network. Phillip's comments are absolutely correct. It works but prefer Device Net.

I am old enough to remember selling and supporting the Hitachi/TI "black boxes" Phillip. "D" type if my memory serves me correctly. Get a spike in the factory and shut down because a section of ladder had moved in the PLC. I guess not too many people have seen that one. Kept me in good money for a long time re-loading programs on all sorts of machines in foundrys, machine shops and even Australia's largest automatic gear box manufacturer. You are absolutely right about open systems and I hope people take advantage of Device Net for that, and many other, reasons.

I guess the biggest problem with Device Net is the price of some of the equipment. I particularly like the AB Powermonitor 3000, although one's first time at explicit messaging can be a bit daunting. Once working it works very well.

My biggest wish, at the moment, is for a simple and inexpensive power monitor with limited functions and a Device Net interface. I use simple power monitors all the time. Usually only require current, voltage, frequency, power factor, kW, kVAR, kVA and a pulse will do for kilowatt hours. Plenty of these available on Modbus - IME, Crompton etc. They are very inexpensive and do the job without the expense of having harmonics etc built in. That all adds to the cost. AB, you have inexpensive metering equipment without comms interface. How about adapting these to Device Net and keeping the cost down. I am sure you would sell plenty of them.

If anyone knows of a cheap power monitor with Device Net interface, please let me know. I can hardly wait.

GE-Multilin - how about making a Device Net interface available for your excellent range of protection relays.

Caterpillar apparently had a Device Net interface in the pipes for their generator controllers. The latest information I have is that it has been discarded for the EMCPIII and replaced by a Modbus RTU interface. That is more than welcome instead of the X?? protocol they used. Writing code for that was a pain but necessary because Modbus was not available. They make enough of these things. Why not a Device Net interface as an option?