DeviceNet or ControlNet

S

Thread Starter

Simon

I have an application that I am unsure the best direction. I have a VFD that controls a slurry pump I would like to add to my network (60 PLCs - AB, Modicon & Siemens) by connecting it to an exisitng AB PLC. The purpose of adding it to the network is to diagnose problems by logging status, power output and frequency output (no control by PLC yet but in the future possible).

The VFD can only be configured for DeviceNet by adding a DeviceNet Communication Option Unit. I am considering the costs of DeviceNet Communication Option Unit + wiring + programming vs. New AB drive with ControlNet + wiring + programming. Right now ControlNet is slightly larger but having a ControlNet cable to this area will allow me to add a remote I/O later on for future control. I believe this could be done with DeviceNet but not as effectively. My company is trying to standardize in ControlNet but when is it over doing it? Any help would be much appreciated.
 
Controlnet will definetly be faster, and more deterministic (you can be sure data will get there on time). You will be limited to "almost" only A-B stuff....

distance and throughtput is also an advantage

on the other hand, Devicenet will let you "talk" to more component/company, but is a lot more harder to configure/maintain ...

regards,
jasmin
 
T

Trevor Ousey \(List\)

My opinion is if the PLC is a Controllogix then Controlnet to the drive can give you easy access to the parameters of the drives, but this can also be achieved relatively easy with Devicenet. Remote IO on devicenet is quite simple and reliable. We have done a lot of drives and IO on Devicenet and happy with the results, but have looked at going with Controlnet for the drives and feel it could be a better system.
 
At my company we use both ControlNet and DeviceNet extensively. ControlNet is faster and better suited to ControlLogix, (for one obvious reason that it delivers 32 bit data words.) However, with the rising popularity of Ethernet based protocols, it seems to me that ControlNet isn't becoming as widespread as DeviceNet has. I don't know if this is due to the Ethernet popularity or the tight reigns of Allen-Bradley. The third party vendor base is not nearly as wide-ranging as is for DeviceNet. If determinism is critical, Ethernet may not be the way to go. But if it isn't you might investigate that avenue.
 
Do not use AB at all but do use DeviceNet extensively with Omron. It works really well with all brands of digital I/O, power monitors, absolute encoders etc etc.

Had a look at the AB DeviceNet configurator and have very definately decided to stick with Omron.

Would recommend DeviceNet. You are not stuck with 1 supplier. I have used Omron, AB, Wago, Pepperl & Fuchs etc with DeviceNet with no problems.
 
ControlNet is an interesting system with caveats. I've been using it (version 1.5) on both PLC5s and ControlLogix systems since 1999 for PLC to remote racks and peer to peer comms on about 40 PLC processors. Although it is deterministic and relatively fast, its downside, especially with PLC5s, is the faulting of processors when the network experiences power switching transients. Using remote I/O attached via ControlNet requires the use of AB's RSNetworx software which is marginal at best.

ControlNet works well in localized high-speed machines but I would not use it again for a spread-out network such as those found in water treatment plants. Ethernet is the direction to take for future projects.

I would also question the use of digital protocols for VFD control in general. Depending on the sophistication of maintenance staff, troubleshooting nearly always requires programming skills. Even installation by factory authorized service providers can be painful because not all of them know how to deal with the communications setups. If staff has a strong technical and programming background, great - but a milliamp signal is straightforward for most.
 
T
Standardizing on ControlNet? WHY? I work on VFDs, PLCs and control systems for a living and I cannot think of any reason for a company to do that - other than perhaps the instance where the company is already fully AB except for a couple of devices.

AB intentionally changes all of their central equipment to NOT work with any standards - this way they keep you locked into their equipment. They recently did this with the new SafetyNet - a DeviceNet safety relay system. With this new specification a company can actually use a serial protocol to monitor and control safety aspects of their equipment and tie it into their pre-existing DeviceNet (this was previously not allowed). However, shortly after partnering with OMRON and SINC to develop this new industry standard, AB CHANGED the code in their SafetyNet devices so that it would not work with anyone elses. This may not seem to bad to begin with - as AB has so many OEM contracts and their devices come preinstalled on much industrial equipment. But wait till you try having those AB devices repaired! OMG!! AB charges an arm and a leg for parts. For instance - a control board for an AB VFD will cost your company 2 - 2 1/2 times the cost for other drives that are just as good or better (Mitsubishi, Yaskawa, etc...) and those other drives will work together over the SAME DeviceNet network.

To Rockwell: IF YOU ARE GOING TO SAY YOU ARE USING A STANDARD THEN USE IT!!!

Hey, do as you like - just be warned. Complaints about Rockwell AB are going way up and they are losing market share to other competitors. Rockwell bought AB and has been sitting back on its (AB's) laurels - sucking cash out of companies through the back door (bend over baby) while pretending that it is not their fault ("...XXX company doesn't know how to do DeviceNet properly"). I have actually heard an AB rep say that.

Rockwell AB makes some decent equipment but they give it away to OEMs so they can stick it to you (the end user) later when no one elses DeviceNet will work with their equipment.

Okay, end of rant...
 
Top