I was wondering if anyone had any comments on devicenet verus ethernet usage for plant comms.
Also, has anyone had any serious problems w/ AB devicenet ?
Mark Riche, P. Eng.
Electrical Design Engineer
Northwest Territories Power Corporation
4 Capital Drive
Hay River, Northwest Territories
ph (867) 874-5266
Fax (867) 874-5264
Personally, I think the decision is one of what you are going to do with the communications and what your communication standards you want to use. I would consider troubleshooting and diagnostic equipment and installation and connectors. I tend to favor ethernet/TCP/IP unless it is an application that it just will not work.
Device net with RSLogix5000 - had problems with VSDs. If VSD failed and was replaced - the VSD version had to be EXACT same model or else would have to reconfigure, download and cycle power on the scanner module.
Not very useful for plants where a shutdown is a big deal!
Maybe this has been fixed in later versions?
Connecting and configuring the Device Net Scanner module was also very flaky - couldn't consistently connect!
Isolating a VSD occassionally kills the DNet - reset by cycling power.
A huge amount of info is available from VSDs on DNet - only thing that was of any interest to plant operators was the amps!
DNet - all pain no gain!?
I think some of your problems you described using DeviceNet with the ControlLogix are fairly easy to explain, and I'd like to offer a little advice. Too often customers first experience with DeviceNet is a painful one because the essential books and tutorials weren't offered to them. DeviceNet is more complex than RIO, that's a fact. I also am SO glad to be done with block transfers !
When you add a device to the scanlist of the 1756-DNB, there are a set of "Electronic Keying" checkmarks on the right side of the scanlist addition window that apply to each connection. They're marked "Device Type", "Vendor", "Product Code", "Major Revision" and "Minor Revision".
These electronic keys are the DeviceNet incarnation of those old white plastic clips you'd place in a PLC-5 chassis to keep maintenance from putting a DC card into a spot that was supposed to hold an AC card, and so
forth. Many people didn't use them, but they were there for a good reason.
A-B DeviceNet scanners send messages when establishing communications with a slave device for the first time that check as many of those electronic keys as you enable. By default, they're enabled down to the Major Revision, because that's the level at which a control bit might do a different function depending on which Major Revision you had.
AC drives, especially A-B ones with Scanport interfaces, are pretty stable; the start/stop/run/jog pattern in the command word has been the same since the early nineties. But each voltage and interface type and firmware level
makes for a different "Product Code" key. In most mills I've commissioned, we turn off the Product Code key, and sometimes the Device
Type key, when we use AC drives on DeviceNet.
I don't use Auto-Device-Replace with AC drives, as there's so much data in them it makes more sense to reload it from a HIM module memory or from RSNetworx for DeviceNet. Typically drives take more than a couple of minutes to replace anyhow... ADR was made to speed changeouts that take just a few minutes.
The 1756-DNB version 3.005 had a bug that made it unbrowseable if you sent it a browse command across the Logix backplane while the DeviceNet port was powered down. This was fixed in later firmware revisions, and really didn't show up much after commissioning because the network power is on. I can't say if that was your problem, but I saw it rather a lot during
startup of systems that had multiple DNB's in the chassis because different users were browsing the chassis for different reasons while I was working
on the DeviceNets.
If removing a drive from the DeviceNet actually caused a bus-off error, you've probably got a shielding or termination problem on the network.
DeviceNet nodes have to be able to be added and removed from the network without causing a bus-off or they don't get the checkmark. That's one of the benefits to the trunk/drop architecture; one broken wire or removed plug doesn't take down the whole network.
Good luck out there,
Oh, yeah, I meant to mention the excellent slide-show tutorial that comes with RSNetworx for DeviceNet, which was written by my friend Joe Kallal in San Francisco.
It's head and shoulders above the DeviceNet Manager's functionality and the tutorial is really good at explaining every control on every pane of the dialog windows when you're configuring.
We've been using Devicenet here in most of our automated test fixtures for some time. Their flexibility, and ease of use make them a good choice for us.
Our equipment is also put through enviromental testing. Fixtures have accidentaly been left in +80C for an entire weekend with NO cooling connected, and they still worked fine. (for now anyway) We've also had no problem with the Devicenet at -40C (the festo valves are another story)
NI has some pretty neat new ethernet remote devices. The SLC 5/05 is ethernet compatable, so there must certainly be a ton of remote devices available for it as well.
For the moment though, we're still sticking with the older tech.
Ethernet and DeviceNet are really two different levels, if implemented properly. Ethernet should be used for peer-to-peer type communications
(ie. processor to processor), whereas DeviceNet is by design a Master/Slave
network. This should be implemented as a processor to I/O or device communication. Ethernet controlled I/o, in my opinion, anyway, is not
optimal because of possible packet collisions, timing issues, etc. If
someone decides to roll a backup tape across a few servers, your network
traffic spikes, and your response time drops. (Yes this happened to me. I
wound up installing a seperate network, hubs, etc. with a packet filtering
Cisco router between the 'production' network and the 'business' network).
DeviceNet is limited in the numbeer of nodes it will support (32). It is a
major pain to setup initially. However, once it is in place, and *properly
configured*, I have found it to be rock-solid. Do yourself a favor, and
make sure all your devices are able to have their address assigned thru
software (not needing the thumbwheels). Enable all of the ADR (Auto-Device
Recovery) options. This way, when someone wipes out a sensor with a
forklift, replacing the 'smart' sensor is just as easy as replacing a
3-wire. You just unplug the old, and plug in the new. The scanner module
identifies the new component, downloads all the configuration data to it,
and re-assigns the node address.
A minor correction: DeviceNet supports 64 nodes, although practically speaking you have to leave a couple open for configuration and maintenance, and you would seldom that many nodes.
Eric M. Klintworth