Strangeness on CAN network

[ruutboy]

Hi all,

We use DeviceNet here at work, which is a form of CAN and we have been plagued with numerous failures in the connections in our tees. Usually it is a matter of finding the offending tee, opening it up and then reclosing it to fix the problem.

But lately we have seen a higher than normal resistance looking through the de-energized system with a ohmmeter (with one terminating resistor removed, the resistance ideally should be 121 ohms). It has ranged from 141 ohms to 320 ohms.

Now here is where it gets weird.

As we are tracking down the tees (these tees are located up above our ovens and are difficult/dangerous to access. So it takes awhile to get from one tee to the next. As I am watching the ohmmeter (a Fluke 789) back in the control shack, I am seeing that the resistance is steadily increasing one tenth of an ohm every 15 seconds or so. So far it has appeared that this resistance will climb indefinitely, or until we find the problem.

So what I figured I was seeing is the meter itself charging a capacitor in the circuit. Sounds reasonable anyways. So the standard thing to do in this instance is to short the leads of the meter together to drain the cap and bring the readings back in line. I did this, to no effect. It just stayed where it was once I opened the short. I suppose that I could be forward biasing a diode in the circuit (the next time we see this, I'll swap my leads around to see if that fixes it).

The other odd thing is that these cables are run in cable tray from one device to the next. The two times that we have seen the "wandering resistance", the problem has been fixed by simply walking by the cable in question. The first time I wondered how our electrician got it fixed so quickly (the control shack is one floor down and at least a hundred feet away from where the electrician is working, so there is no way that I can see what he is doing at the time). The second time the work was done by a different electrician who called back down and told me that he hadn't done anything other than walk by the cable. Try as we might, we were not able to recreate the fault.

Any thoughts?

Thanks.

[Jan Axelson]

About all I can offer is some suggestions. You may have already tried these.

See if you can recreate the resistance issue on a test setup (not your working equipment).

Define what is failing as precisely as you can. For example, no data received or sent? By one device or more? Does it happen on random devices or do a few devices fail repeatedly? If it's the latter, is there anything different about these devices (cable length?) Does the problem go away on its own sometimes besides the two "walk bys"?

Can you monitor the signal levels and noise?

[ruutboy]

About all I can offer is some suggestions. You may have already tried these.

See if you can recreate the resistance issue on a test setup (not your working equipment).

We can do a test setup on a system that has been down for years. It would work nicely for that. As for what is failing, on the night that I described, we received the report that the network was down, but everything was running when we got up there. But it's no problem shutting down a network for a look-see if we aren't running production. So we went ahead and did this and that's when we found the 141 ohms. So it was surely on its way out.

Define what is failing as precisely as you can. For example, no data received or sent? By one device or more? Does it happen on random devices or do a few devices fail repeatedly? If it's the latter, is there anything different about these devices (cable length?) Does the problem go away on its own sometimes besides the two "walk bys"?

It's largely limited to five networks, and the usual fix is to take the network down and using an ohmmeter, monitor the resistance as we open and close connectors. We had been looking at it with a scope, but it became apparent that a ohmmeter worked better. What appears to be happening is the ControlBoss connectors are coming loose and creating either a high-impedance junction, or in extreme cases, complete loss of one of the CAN signals or the Network power that goes along with it.

Sometimes the fault is announced by a "Bus Off" condition (essentially a heart attack for a CAN network), any other time it would be some or all of the devices on the network disappearing.

The cabling was done using factory made cables. And while that might sound attractive, you end up having to do something with the excess cables. In our case, they are looped back and stuffed in the cable tray. As you know, excess length in a CAN network is never a good idea. That and the minimum bending radius of the cable is ignored to get it folded back (these are 8 conductor cables).

Because of the cable size (approximately 5/8" - 3/4" in diameter), the weight and stiffness can cause connectors to come loose.

As for failures based on cable length, there seems to be no difference based on length. Any cable can fail, it really makes no difference.

And for the problem going away on its own, we never seem to have the time to wait, so I'll never know.

Can you monitor the signal levels and noise?

We can monitor it through a few different methods. We can either use a DeviceNet monitor that does a good job of tracking numerous different types of faults (rise time, noise, voltages in regard to ground and in regard to the other CAN signal, along with about twenty other different things). But it falls short on an accurate representation of the waveform. For that, I've got a Rigol DS1102E that I can connect to my laptop to collect data in real time.

I'm familiar with our normal noisy signals. It would be interesting to see what's different when this failure occurs.

The bad thing is that we never know when or where this is going to happen. And where...


Thanks!

John