DeviceNet Choke?

[sportster]

We have about 25 networks in our plant and have two in particular that have been giving us trouble on/off for months now. Yesterday we were discussing these problems with our electrical contractor. He told us that another firm in the area uses "chokes" on all of their DeviceNet connections. They strip the outer protective layer and shielding off, slip the "choke" ring on the cable, and then terminate the five network wires as normal. I'm putting the word "choke" in quotes because that was the what the electrical contractor called them and I'm not sure that is the correct term. He said they looked like little metal donuts that the cable was passed through.

Has anyone ever heard of/seen this being done?
Does it make sense?

To me it sounded like they were trying to cancel out any induced voltages on the DeviceNet wires/cable. But isn't that why proper grounding is so important? I should note here that all of our systems are grounded correctly according to the AB Media guide for DeviceNet.

Any feedback or discussion is welcome.

 

[jimfun71]

Ther magnetic rings. While I have seen them on all the power leads of VFD'S I have never seen them on devicenet comm lines.
Make sure all your connex are good and tight. Make sure you have a 120 ohm resistor on the end of your devicenet run.

 

[widelto]

This is what i have used with great success. put them around the devicenet cable ( thin one) and your noise problems dissappear.

 

[Ken Roach]

"Choke" or "ferrite core" is the most common term. They're made out of ferrite, the magnetic material that forms the core of most signal transformers.

At the risk of horrifying our EE members, a layman's explanation: They damp out the high-frequency noise signals by converting the magnetic fields of the high-frequency signal to a tiny amount of heat, while damping the lower-frequency signals less. I start to get dizzy if I hear "lumped-shunt parasitic capacitance".

These are only going to be helpful if the problem with the network is from induced RF noise. I'd recommend that you spend a little time with an oscilloscope and a Woodhead NetMeter, or I 'd have to know there are powerful RF generators like motion controllers nearby, before I'd recommend installing a lot of these.

The split-core type that will clamp onto the cable are especially convenient.

 

[sportster]

Thanks for the clarification guys.

Ken, I have had a NetAlert meter from Woodhead on the two trouble networks. I would have to look at the log book, but I don't remember any readings been out of line. Would an o-scope give more information? What would a person have to look for/measure?

 

[Clay B.]

Thanks for the clarification guys.

Ken, I have had a NetAlert meter from Woodhead on the two trouble networks. I would have to look at the log book, but I don't remember any readings been out of line. Would an o-scope give more information? What would a person have to look for/measure?

The O-scope can show you the noise. It will show the higher frequency noise that is on the signal. I have never used a NetAlert meter so I have no idea what it shows.

If you have drives close to your com cables at certain times (while in motion) you may see spikes of RF noise on your com cables.

I would like to add that everytime I have seen this though someone double grounded the sheild on the comms cable or the ground had noise on it usually an improperly grounded drive.

 

[Ken Roach]

The NetMeter is the absolute best tool I have for working on DeviceNet networks because it gives you a nodes-eye view of the network.

One of the most useful things the NetMeter can do is that it will count the number of bad CAN frames it sees on the network. The default setting (I think it's dial position 2) is for bad frames/second overall, but you can also use the selector buttons to show total bad frames, and total or rate per node.

I use the NetMeter as a complement to a scope, because a signal that looks noisy or distorted to my eye on a scope might be perfectly good from the perspective of the CAN transceivers on the network.

Let's take a bit of a step back and discuss what the problems are that these networks have been displaying. Are individual devices faulting and reporting network failures ? Are you getting a "bus off" error on the scanner ?

 

[The Plc Kid]

We use this http://www.fte.com/products/NetDecoder.aspxfor troubleshooting devicenet networks in addition to a woodhead devicenet meter as ken said.

It handles all our AB networks and some others too. Uses standard AB cables.

 

[Honga]

Just FYI something like 94% of all deviceNet problems are from poor installation!

Just sayin'.

 

[sportster]

Ken, what we are seeing is two seperate problems. The first problem is devices falling off the network. We will get a "78" code relating to a device. The second problem is corrupted commands being sent to the drives (drive running reverse when plc logic says that it should be commanded to run forward).

It is always nodes 1, 2, or 3. See attached pdf for network layout. Cable daisy-chains from device-to-device and total cable length isn't more than 30ft. The cabinets are small (36x36) so the network cable is closer to the 480 wiring than probably acceptable; but it isn't any worse than our other networks that have no problems.

I should also add that we have four "roughly" identical machines like; only two have problems. We have tried to compare them to find differences, but haven't come up with anything.

 

[sthompson]

Ken, what we are seeing is two seperate problems. The first problem is devices falling off the network. We will get a "78" code relating to a device. The second problem is corrupted commands being sent to the drives (drive running reverse when plc logic says that it should be commanded to run forward).

It is always nodes 1, 2, or 3. See attached pdf for network layout. Cable daisy-chains from device-to-device and total cable length isn't more than 30ft. The cabinets are small (36x36) so the network cable is closer to the 480 wiring than probably acceptable; but it isn't any worse than our other networks that have no problems.

I should also add that we have four "roughly" identical machines like; only two have problems. We have tried to compare them to find differences, but haven't come up with anything.

Is there a proper Termination Resistor at each end of the Main Trunk?
Is the Devicenet Network powered by it's own proper Power Supply?
Are these Devices all in one Cabinet, or spread out?
What is the total distance from end to end of the Network?
How are your connections done to your VFDs, Looped or Taps?
What kind of Cable are you using, round or flat with Vampires?
What Devicenet Communication Baud Rate are you using?

Stu.....

 

[Honga]

What scanner are you using?

 

[Ken Roach]

I want you to keep in mind as we discuss this that the problem might not be the network. The network might just be where the problem's symptoms can be viewed.

I think this for two reasons:

1. Error 78 is displayed when a device fails to respond to a DeviceNet explicit message. Usually there are three retries a second apart, so seeing an Error 78 code indicates that a device is really, truly, genuinely disconnected from the network. Often Error 78 indicates that a device has been unplugged or powered down. I think you'll agree that while being unplugged is "network related" that it's not a network problem as such.

Intermittent device disconnections due to noise and interference are usually brief, and are indicated by an Error code 72. If the messages that the 1769-SDN sends to re-connect to the slave device are still not responded to, the Error 72 turns into an Error 78 after 3 to 4 seconds.

You can set up logic traps to evaluate what the error codes are, and for how long.

My next diagnostic question is: how do you correct the Error 78 ? Do you cycle power to the DeviceNet, or to the scanner, or to the drive, or does it just reset itself ?

2. I think you posted another thread about the Bulletin 160 drives changing speed or direction without you intentionally commanding them to do so in your program. You've attributed this to "corrupted commands" in the network packet.

This is extremely improbable.

DeviceNet uses two data integrity mechanisms; "bit stuffing" parity down at the CAN level, and a 16-bit CRC error check at the protocol level. The odds of an electrical disturbance of the DeviceNet CAN bus data stream resulting in an undetected data corruption are extremely low; I have seen estimates that statistically show a CAN network with errors introduced into one packet out of every thousand will have an undetected error once every 1000 years.

It's very unlikely that the data is being sent incorrectly by the controller. This has actually happened in some DeviceNet scanner firmware (under very unusual circumstances) but I've never heard of it with the 1769-SDN.

If I were investigating this issue I would install a logic trap in the controller to find out if the Output data table element for the reverse direction is ever being set when we don't intend to set it. I would also install a DeviceNet traffic analyzer (A-B or FTE) and capture the data immediately before the "uncommanded direction change" event.

What if it's possible that an indirect addressed bit of logic, or something on the network is writing to your Output data table ? That's what you should be able to trap in logic. It's unlikely but you can rule it out with a little logic.

 

[Ken Roach]

The Bulletin 160 drive uses an internal 12V supply and contact closures for the discrete inputs on the drive. While these are cheap and simple and great for local pushbuttons and selector switches, such interfaces can be subject to malfunction due to induced voltages.

Are there any local selector switches or pushbuttons connected to the Forward / Reverse or Speed Select pins ?

Even if there are not, make sure that the common pin (TB3-3) is tied to a solid signal ground.

I would guess that there is something going wrong with the drive itself, rather than with the network. But that's just a guess until we try some stuff to rule out the network.

 

[sportster]

Stu, To answer your questions:
1 Yes
2 No it shares a PS with the panelview
3 The scanner and 3 drives in one cabinet, the other three in another cabinet 3" below the first cabinet (don't ask)
4 Roughly 10-12 feet total cable length at the most.
5 I quess I'd say looped from drive to drive.
6 Thin cable
7 125Kbs baud rate

Ken,
1 To clear the "78" fault we cycle power to the drive.
2 I checked the program again to make sure that nothing is over-writting the M File for the Scanner.
3 There aren't any buttons wired to the drives.
4 Can I tie TB3-3 to the cabinet ground? Everything in these cabinets shares the same ground.
5 How is grounding TB3-3 different using the ground screws on the drive?
6 It will take me a day or two to get some logic traps programmed in to check for fault code number and duration.