Error handling and diagnostics
EL6752
96
Version: 2.1
Test 7
Use a DC ammeter (16 A max.) to measure the current between the power supply ground and the screen at
the end of the network most remote from the power supply unit. An equalization current should be present. If
there is no current, then either the screen is not connected all the way through, or the power supply unit is
not properly earthed. If the power supply unit is somewhere in the middle of the network, the measurement
should be performed at both ends. When appropriate, this test can also be carried out at the ends of the drop
line.
Test 8
Interrupt the screen at a number of locations and measure the connection current. If current is flowing, the
screen is earthed at more than one place, creating a ground loop.
Potential differences
The screen must be connected all the way through for this test, and must not be carrying any current - this
has previously been tested.
Test 9
Measure and record the voltage between the screen and the power supply ground at each node. The
maximum potential difference between any two devices should be less than 5 volts.
Detect and localize faults
The "low-tech approach" rule is the best localisation method: disconnect parts of the network, and observe
when the fault disappears.
But: the approach based on this method is inadequate in the event of problems such as excessive potential
differences, ground loops, EMC and signal corruption, since in many cases making the network smaller
solves the problem notwithstanding the fact that the "missing" component may not have caused it. The bus
load also changes as the network is reduced in size, which can mean that external interference "hits" CAN
telegrams less often.
Diagnosis with an oscilloscope is not usually successful: even when they are in good condition, CAN signals
can look really chaotic. It may be possible to trigger on error frames using a storage oscilloscope - this type
of diagnosis, however, is only possible for expert technicians.
Protocol problems
In rare cases, protocol problems (e.g. faulty or incomplete DeviceNet implementation, unfavorable timing at
boot up, etc.) can be the cause of faults. In this case it is necessary to trace the bus traffic for evaluation by
DeviceNet experts - the
can help here.
A free channel on a Beckhoff FC5102 CANopen PCI card is appropriate for such a trace - Beckhoff make the
necessary trace software available on the internet. Alternatively, it is of course possible to use a normal
commercial CAN analysis tool.