We have an appilcation for a shopping mall, where 9 PLC's need to be networked together. We have the choice of either DeviceNet or Profibus. The total distance is 500 meters. We do not have much experience with either bus. We'd like to hear comments regarding ease of use, reliability, performance, etc.
Thanks in advance.
It is probably a matter of preference, availability of hardware, handling of data in the brand of PLC of choice and perhaps guided by what is available to you in your common preference of PLC.
My preference is Device Net for several reasons.
1) Our common PLC brand is Omron and they are members of the Device Net organisation. Their support of Device Net is fairly complete.
2) Device Net I/O and specialised hardware components are readily available in Australia. For example, we recently used Allan Bradley Powermonitor 3000 devices on Device Net along with many Omron I/O blocks. We are pesently using Omron Device Net I/O blocks and Pepperl & Fuchs Device Net multiturn absolute rotary encoders on another job. Pepperl & Fuchs encoders were 2/3rds of the price of Allan Bradley and Danaher.
Have a look at the support your preferred PLC has for both technologies. Most PLCs support both busses these days. The last time I used Profibus was with Siemens PLCs (you either luv em or hate em). I found send and receive commands and the timing of both drove me nuts. With Device Net I used the Omron configuration software and found all digital I/O blocks automatically. Each network did not take very long. With the Omron configuration software I was then able to allocate the various blocks to high I/O memory areas in the PLC, well out of the way of any likely rack or remote mounted I/O. The Allan Bradley Powermonitor 3000s were a little harder, using EDS files, but mainly because of the amount of data they can supply, you have to use explicit messaging. Once set up it worked like a dream.
I was faced with this same decision some months ago, and I compiled this feature comparison:
Profibus DP DeviceNet
Maximum nodes 128 64
Data Throughput 12 Mbaud, max 1/2 Mbaud, max
Maximum bus length 32,800 ft 1,640 ft
Maximum bus length
at maximum baud rate 3,280 ft 328 ft
Cabling 0.30" dia 0.65" dia
Configuration Software Free $995 + yearly
Ease of Configuration Good Good
Ease of Startup Good Fair
DC Power Supply for bus
power None required Dedicated, $425
Larger than a breadbox
Slave data accessible from multiple masters
I would like to make a bit of comments about this comparison (which is in general terms quite good)
-DeviceNet does not require a dedicated power supply (any 24VDC power supply is acceptable) I had to installa a DeviceNet network some time ago and choose the 1787-DNPS, but under a burnout of this one I installed an Omrom power supply and it didn't was a trouble).
DeviceNet is a producer/consumer network, not a master/slave one, so data can be accessed from any device that need it. Furthermore, it allows peer to peer communications, and if multiple devices want to communicate with one to get the same data, it doesn't affect the overall bandwith of the network (which is, in my opinion, very limited).
Anyway, the point is the objective of the network. DeviceNet is intended to cover field communications, such as I/O, operator interfaces and small PLCs, and does not work well with large amounts of data such as required for control applications, for example. In this case, the distance to be covered is 300 meters, so probably the user will be limited to 125 kbps and 64 nodes. I suppose this will be a great limitation.
I didn't say "special", I said "dedicated", meaning that the network should have its own power supply that is not used elsewhere. Even then, I have had Allen Bradley tech support make sure I was using their power supply when I called about a non-functional DeviceNet installation. The specs for the power supply performance are actually pretty tight. So, even if you don't think a special DeviceNet power supply is, or should be, required (and I tend to agree), the people whom you will expect to provide support for the network, think one is.
At 13:18 19.10.02 -0400, Marcelo wrote:
>Steve Myres wrote:
> >I was faced with this same decision some months ago, and I compiled this
>feature comparison: ....<
>I would like to make a bit of comments about this comparison (which is
>in general terms quite good)
>-DeviceNet does not require a dedicated power supply (any 24VDC power
>supply is acceptable)
DeviceNet needs at least one single common power supply ... which could be a single point of failure.
>I had to installa a DeviceNet network some time
>ago and choose the 1787-DNPS, but under a burnout of this one I
>installed an Omrom power supply and it didn't was a trouble). DeviceNet
>is a producer/consumer network, not a master/slave one,
Sorry ... it's vice versa. DeviceNet is a master/slave network. (ControlNet is a producer/consumer network).
> so data can be accessed from any device that need it. Furthermore, it
> allows peer to
>peer communications, and if multiple devices want to communicate with
>one to get the same data, it doesn't affect the overall bandwith of the
>network (which is, in my opinion, very limited). Anyway, the point is
>the objective of the network.
That's excactly what the DPV2 protocol of PROFIBUS DP does :)
> DeviceNet is intended to cover field
>communications, such as I/O, operator interfaces and small PLCs,
I have seen PROFIBUS DP <-> Ethernet a gateway embedded in a PROFIBUS plug ... so PROFIBUS
devices are in the meantime also very tiny.
>does not work well with large amounts of data such as required for
>control applications, for example. In this case, the distance to be
>covered is 300 meters, so probably the user will be limited to 125 kbps
>and 64 nodes. I suppose this will be a great limitation.
Yes ... max 8 bytes per frame is not much -> just two 32 bit analog values. Event oriented communication can help in some cases ... but if you have e.g. to measure analog values with a high time resolution 1ms then there is no chance to do it with CAN or DeviceNet.
About speed, I must explaine something.
With Profibus (on Siemens controller), each CPU cycle time, you will refresh all of your I/Os cards. That means a lot of communications for no reason.
With DeviceNet, comunication are of events. When an input change his stat, it send a message. That means, with this system, you don't need a fast speed. Then low cost cables ...
> Ease of Startup Good Fair
Startup is a little bit more complex than Profibus, but you have a lot of advantage.
When you change a drive with Profibus, you must download yourself all the paremeters. That means that the final customer must call an engineer to replace a drive (and Siemens software ...).
With DeviceNet, you can stor the drive parameters on DeviceNet Scanner. Then, when you change the drive, just plug and power up the one. All parameters will be dowloaded without operation.
The customer just nedd an electrician to replace the device. Time and money saving.
You can not just compare like you do. You must compare also the features. If you need more, let me know.
DeviceNet is a greatful network for devices. His maximum length is 500m.
To communicate between 9 PLCs, I fully recomand to use ControlNet. With this, you can have some deterministic, repeatability data transfer, instead of Profibus.
If you need more informations about DeviceNet, ControlNet, e-mail me.
While I agree that the most important criterion is going with a solution you from someone you trust, I have personal preference for Profibus. While it's true that DeviceNet can send messages and therefore not soak up uneeded bandwidth, the maximum throughput on Profibus is much better.
Both networks have a best-cycle-time of around 2ms, DeviceNet can only transmit 8 bytes of data in that cycle. Profibus can transmit 244 bytes. On a system with four drives connected on profibus using 16 bytes of input and output per drive, it would take at least 16ms over DeviceNet vs 2ms for Profibus. If I have 8 drives, DevieNet will take 32ms. Profibus is still at 2 ms.
For small stuff (photoeyes, proxes, etc.) connected directly to the network, I think AS-i is easier to use and better suited to the task.
Basically, I think DeviceNet is too small for the big stuff and too big for the small stuff.
Sage Automation, Inc.
My take on DeviceNet is that with DC power included, it would make a good bus for a fairly small number of sensors (~50) distributed thinly over a large physical area. That way, you would have sensor power built in, on board diagnostics might save troubleshooting time if it takes a technician a while to get to the sensor location. Except that it falls short on bus distance, so in practice, it's not even good for that. Oh, well.
That depends on the choice of your plc...If you choose the siemens plc, then best to go with Profibus since the plc native supports for the protocol is the one of the best. On the other hand, if you are using the Allen Bradley PLCs, then DeviceNet is the way to go...Likewise for the other plc vendors.
With both buses, you have a host of options available to you. Also, you would find that most european installations are profibus based (Siemens
based) whereas the North American projects are devicenet based (AB based)...
SHAHID WAQAS CHAUDHRY wrote:
>That depends on the choice of your plc...If you choose the siemens plc,
>then best to go with Profibus since the plc native supports for the
>protocol is the one of the best. On the other hand, if you are using the
>Allen Bradley PLCs, then DeviceNet is the way to go...Likewise for the
>other plc vendors.
>With both buses, you have a host of options available to you. Also, you
>would find that most european installations are
> profibus based (Siemens based)
No ... this doesn't fit to the European reality :)
The reverse might be true ... Siemens is PROFIBUS based.
But PROFIBUS is 'Siemens based' is only true in some extent.
The majority of all PROFIBUS based devices are not provided by Siemens.
>whereas the North American projects are devicenet based (AB
I'm not convinced that this simplified view is true ... are DeviceNet based devices offered by AB only?? Does AB all DeviceNet projects ??
>I'm not convinced that this simplified view is true ... are DeviceNet based devices offered by AB only?? Does AB all DeviceNet projects ??<
No. AB is the big name attached to DeviceNet, but Omron is also a founding member of ODVA, and IMHO has a cleaner implementation of DeviceNet than AB does. There are many others that distribute DeviceNet components as well. Check out "http://www.odva.org":http://www.odva.org for details....
In your message you say:
>where 9 PLC's need to be networked together.
you did say,
You don't network 9 PLCs together with one another over DeviceNET. DeviceNet is intended as a Device level Network. Not a peer to peer network and certainly not a "plantwide information network"
For Nerds Only: It IS possible to do peer to peer with DNET bridges, or with Explicit Messenging between masters, BUT WHY? You only do that if you are somehow over-a-barrel.
Profibus is a 'better' choice because of it's Peer to Peer support as well as high speed as well as... well, every compareable spec. See some of the other posts for specs.
So if you had ONLY THOSE TWO to choose:
BUT, if you have an opportunity to specify a different communication method please visit:
They have great information on bus systems. They support all the buses, so they don't really play favourites.
Also, sometimes the most cost effective high speed communication available for 9 PLCs is actually a combination of buses and communication types.
Remember, to connect your computer to the PLC via Ethernet might cost $cheap for you PC's Network card, but it may be a $$expensive option for your PLC to communicate ethernet. OR maybe your PLC has profibus DP available built-in, but a Profibus card for your computer will be at least big $$.
What I have known some plants to do is use a cheap proprietary network to connect the PLCs to one another ($medium), then have an Ethernet interface on ONE of the PLCs that supports a "gateway" function.
Another company provides "Web Enabled Controllers" which are like smaller stand alone PLCs which have ethernet ports built in. They can be programmed remotely, data can be collected via OPC, XML, HTTP, FTP, SOAP etc... Check them out at
pretty neat stuff. All the networking is ethernet which would be relatively inexpensive for a mall, and the programming is all "machine-state" which is easy as pie.
It used to be PLCs were for machine control, and stood alone. Now everything is networked together for monitoring, alarming notification etc... More like computer networks, eventually you will stop plugging that Profibus/DeviceNet into a PLC then try to make that PLC interface with the PC and IT world and just plug your bus cable straight into the Computer. <--- insert "can of worms" opening sound effects.
Good Luck Alvaro, email if you have some questions. Lakesidebc@telus.net
If you need connect 9 PLC to control the all process, I preferred Profibus DP, because this support 12 Mbs, this protocol is for process and DeviceNet is only Bus Field, because you donīt see another vendor, maybe telemecanique have a PLC's with Eternet TCP/IP Family PRemium you conect the 9 PLC over Ethernet or FIPWAY and use (BUS X) for I/O remote or if you need bus field similar to DeviceNet you use Bus AS-i or DeviceNet for Momentum. and you can use Transparent Factory tecnology with web server over PLC. for more information you visit www.transparentfactory.com, si tienes alguna duda contactame por correo saludos email@example.com
I think we all could better help you with your application if you give us some more information.
It's clear to me that you're planning to use 9 PLCs, and you must have communication with all of those. The first question is:
Do the PLCs need to communicate with each other, or you just need to supervise all of them?
The second thing is a question on the number of PLCs you're going to use. Does the 9 PLCs control 9 independent machines or parts of the processes or there are some which are dependent one to the other. The point i'm trying to reach is that you might get a better result if you use some remote i/o instead of just PLCs.
We've had excellent results using the VIPA Speed7 (www.speed7.com or www.vipa.de). Its a Siemens compatible PLC which has integrated Ethernet and Profibus DP interfaces). It supports even EtherCAT.
On our projects, we've used ethernet for programming, supervising and monitoring and profibus DP for I/O and Drivers control. As VIPA is Siemens Step7 compatible, we used the Simatic Step7 Manager which is a powerfull and complete tool for programming, configuring and managing all the application. Lets say that the tool is the best of all once you learn how to use it.
I believe it's the best cost-effective solution.
If you'd like, i could take you to some plants so you can see the results for yourself and talk to the managers and users.
Count on us.
sorry but couldn't avoid replying after seeing this response to a *6 year old* question with shameless publicity for a SIEMENS-PLC copy like VIPA...
Dear forum readers - I would recommend ignoring that previous post and reading the posts from 2003 to get real networking info and I invite all people with experience with SIEMENS, Rockwell, ABB equipment, etc, to share their knowledge of Devicenet vs. Profibus DP...letīs come in here and share some more experiences.