DeviceNet: cordsets vs. hardwiring

Hi All,

I would appreciate if someone can provide me with his/hers experiences with DeviceNet wiring: should I use already available cordsets (Turck, Brad Harrison, etc.), or attempt to do it on my own?

The specs are: 15 nodes, 500Kb, 4 words in/ 4 words out per node, trunk cable distance is max 50 meters.

Regards,
zif

I have never used cord sets, only hard wiring. Cord sets are very limiting as you have to have the exact length you require. Hard wiring allows much more freedom in length between nodes and can be much neater as you do not have to find somewhere to tuck the "leftovers".
Make sure you use a Device Net approved cable. There are 2 flavours, thick and thin. Belden make a suitable cable. Shop around distributors as I have found that prices vary rather wildly. You will have to carefully consider whether you use thick or thin cable as the length of the run at different speeds varies the cable type. The manual from your PLC manufacturer will detail what to use for your application. The PLC manufacturer will most likely be AB or Omron as they are the 2 strongest proponents of Device Net that I have seen, at this stage, although many others like Hitachi etc have scanners and components available. It has now been accepted into the IEC standards group so we can expect some growth of product out of Europe rather quickly.
Phoenix make all 3 types of connectors for Device Net, but beware, they fit almost all devices I have used but AB seem to be using a funny plug, why am I surprised? The Phoenix plugs would not fit into the AB Powermonitor 3000 but fitted every other Device Net device I have used.
beerchug

The best compromise I've seen between the flexibility of hardwiring and the ease of cordsets are junction boxes that A-B calls "DeviceBox"es.

These are little gasketed junction boxes that have two cable-entry gland nuts sized for thick trunk cable, then 2, 4, or 8 cable entries sized for thin drop cable. Inside is a PC board with the DeviceNet traces laid out so all the spring-clamp connections inside are in parallel.

The spring-clamps make terminating the DeviceNet wire easy and are far less prone to wire breakage or shorting out than I've found screw terminals to be.

They're not washdown rated; I have one customer who has a DNet failure every time they pressure wash their machine (they know it, but they keep doing it).

I try to avoid field-terminated cordsets. Those five-pin connectors are very difficult to get good workmanship into, and they're much bulkier than the factory-made molded connectors.

I also try to avoid open terminal blocks. One GE DeviceNet MCC I worked on had the DeviceNet +24VDC terminal right next to the 120 VAC supply terminal. Guess which one survived the clash.

A-B's KwikLink flat-media system costs a little more up front but the installation labor is very low as long as you practice once or twice before going into mass production. I usually don't recommend it for high-noise environments because it lacks shielding; your 4 bytes in/ 4 bytes out sounds like you might be connecting a bunch of AC drives.

One more thing; Avoid daisy-chaining at all costs. It's the least expensive method of connection, but believe me you will someday break a wire and have a hell of a time figuring out where it is. If you use trunk/drop cabling you're much less likely to break the trunk connections and more likely to lose just one node (the termination at the device is almost always where the wire breaks) and know where to look.

Fair comment Ken but I usually find there is so little profit in the job I cannot afford to do it that way. Omron are expensive enough but AB - oh dear!!!! (literally). I usually find that if one uses pin connectors on the wire and the Phoenix double connectors, all is well. There is only 1 wire in each side of the connector and the connector is gold plated so I have not really had any problems.

I would highly recommend the trunk line / drop line layout instead of the daisy chain. We have a network of 13 drives that are daisy chained together and we are now chainging it to a trunk line / drop line setup using AB DevicePort taps because it was a huge hassle to troubleshoot. We had a problem once when half the nodes (GM6's)reverted back to 125 Kb from 500Kb. We didn't know this at the time of course, but trying to tie into the daisy chain network to troubleshoot was horrible. our electricians didn't want the DeviceBox taps because they wanted as few man made connections as possible.

Just my 2 cents.

BobB's method of using crimp ferrules and the 10-point connectors is probably the best way of doing daisy-chaining. I've seen plenty where two stripped wires are screwed into the same cage and the cables aren't even tied together.

I had a customer do a whole MCC retrofit like that, and to make it worse he mounted the I/O blocks on inside of the doors because he didn't want to modify the backplates. It was like he sewed the MCC together with DeviceNet cable.

(hey, Gotcho... want to know how that happens to SCANport adapters ?)

Thanks All,

I believe I would go for trunk/drop line style. The previous project was done with daisy chained nodes (6 of them, one of those "... we just have to make it run" projects), and I consider myself lucky since I haven't received any calls yet.

Regards,
zif

Scan Port adapters

Ken
I would love to know why this happens to our DeviceNet scanner/Impact drives. I thought the Gx6 models would revert to Autobaud, which wouldn't make a difference. We tried a bunch of Tech support people, even some of my friends at Rockwell from when I worked for a supplier, but no one has been able to give me an answer. It only happens to some of the drives on the network and some lose the baud rate and some lose the node address and some lose both.

Any insite would be appreciated.

Sorry for diverting your thread, zif2, I'll keep this short.

Here's the scoop with the SCANport/DeviceNet adapters; this goes for the 1203-GU6 and the 2100-GK61.

The DeviceNet node number and data rate can be changed in two different ways: through the DeviceNet Object (Class 0x03) or through the Parameter Object (0x0F).

The DeviceNet Object is accessed with handheld configurators or the DeviceNet Node Commissioning utility. If you double-click on the node number of a device in the graphical view of RSNetworx, that brings up the Node Commissioning utility. Those changes take place immediately.

The Parameter Object is what you're accessing using the traditional Parameter Editor in RSNetworx for DeviceNet software. The "DN Node Address" and "DN Data Rate" parameters (Parameters 326 and 327 on the drive I have right here) only take effect when power is cycled.

So what usually happens is that a technician browses a DeviceNet with RSNetworx software, but he has a blank project file. When the drive shows up on a network browse, he goes online and answers "Download" when the software prompts him to upload or download in order to go online.

Presto ! He's just loaded the default data rate and node number parameters into the 1203-GU6 (because he hit *download* from a default project file). They don't take effect until power is cycled, which might be days or weeks later.

Other scenarios I've seen include one technician (the new guy) whose standard M.O. was to hit the "default values" button in RSNetworx, then to set up the parameters he knew he had to change (but omitted the node and data rate). When the power was cycled.... ta-da, all the drives he set up were at Node 63, 125 KB/s.

There's nothing to be done except to make sure folks with access to the network have at least a little training in RSNetworx procedures.

"It's not voodoo, it's just DeviceNet !"

Thanks for the info Ken. I'll make sure our people know.

Just to add more flavour to the discussion: if I assign node numbers like 0->master, 11-25->slave group 1, and 5-10->slave group 2, would it be a source for slower communication, as opposed to consecutive numbering?

Regards,
zif2

Sorry Zif2 for diverting this thread. Just one more question. beerchug

Ken
The problem happens with the GM6 (the on board unit). I was looking at the drive parameters last night and they show the baud rate at 125 and the node address at 63, but the drive is communicating fine and is at 500Kb and Node 7 on the network. If power is cycled to the drive it still holds its address (I know this because the operators lock them out once a week during weekly shutdown). If the power is cycled to the devicenet, will those parameters in the drive (125 & 63) replace what the GM6 is actually using (500 & 7)? I may get the to try this on down day, but just thought you might know. I will be checking the manual closer when I get back to work tonight.




Thanks

I cannot answer for AB as I have never used Device Net on one of their PLCs but Omron have a function called something like "enable scan list". This speeds up communications considerably as the scanner does not look for a device that is not there.
I do not know if this will help but I hope so.
beerchug

The way the A-B scanner's sequence of operations goes is something like this for a small example network of five slave nodes, all with Polled I/O connections.

Scanner Transmits Node 1 Output Data
Scanner Transmits Node 2 Output Data
Scanner Transmits Node 3 Output Data
Slave Transmits Node 1 Input Data
Scanner Transmits Node 4 Output Data
Slave Transmits Node 2 Input Data
Scanner Transmits Node 5 Output Data
Slave Transmits Node 3 Input Data
Slave Transmits Node 4 Input Data
Slave Transmits Node 5 Input Data
[several milliseconds of silence; the InterScan Delay]
<repeat>

The slaves don't wait for the scanner to finish transmitting output data to all nodes. When each slave gets it's output data and processes it, it responds with input data as soon as it can get bus access. Some slaves respond faster than others; an E3 overload relay responds within a millisecond, while a Magnetek drive takes between seven and twelve milliseconds to reply.

The scanner does send output data in node order, and lower node numbers do have bus-arbitration priority. There's no practical penalty for having intervals between your slave node numbers, except when browsing (where the software tool does look for every possible node).

A reply to Gotcho's question about the A-B drives:

I was looking at the drive parameters last night and they show the baud rate at 125 and the node address at 63, but the drive is communicating fine and is at 500Kb and Node 7 on the network. If power is cycled to the drive it still holds its address (I know this because the operators lock them out once a week during weekly shutdown). If the power is cycled to the devicenet, will those parameters in the drive (125 & 63) replace what the GM6 is actually using (500 & 7)?

Click to expand...

What's going to happen when the drive itself has power cycled is that it will restart with the 1336-GM6 interface set for Node 63 and 125 KB.

Just power cycling the DeviceNet won't cause the DeviceNet interface to transfer it's NVRAM-stored Parameter settings into the active settings. The drive itself has to have power cycled (or, in the case of 1203-GU6, the SCANport cable that provides 12VDC power is unplugged).

I just tested that myself; 1336+II drive and 1203-GU6 v2.001 running Node 7 at 500KB. I hit the "default parameters" button in RSNetworx, then Apply. Now the Parameters read Node 63, 125 KB but I can still browse and upload and run as Node 7, 500 KB. Cycle power on the DeviceNet; still Node 7/500KB. Cycle power on the drive.... now it's Node 63/ 125 KB and I have to go change my 1770-KFD driver configuration to talk to it.

The drives that are holding their Node Number through a lockout must not have their parameters mis-set.

This is all based on relatively small field experience (I'm a salesman!); there may be something different going on in your particular plant. IMPACT drives especially, somebody might be monitoring them with DriveManager or RSNetworx more often than a typical standard drive, and be inadvertently sending the default settings to the Node/Data Rate parameters.