DeviceNet troubleshooting: the readings that find the fault before you swap a scanner

The call always sounds the same. Line is down, the scanner LEDs are red, and somebody already has a replacement module in his hand. Most of the time that module is fine. The fault is sitting in the media: a connector that was never properly tight, a missing terminator, a shield bonded to ground in two places. So before anything gets swapped, here is what a meter should read on a healthy DeviceNet segment, what every wrong number is actually telling you, and the few behaviors that make good parts look dead.

DeviceNet did not disappear, it went invisible

Rockwell stopped selling the SLC DeviceNet scanner on March 31, 2024. The installed networks stayed exactly where they were.

Some of them everybody knows about. The ones nobody knows about are the problem. POINT I/O is the example I keep running into: PointBus is just the name for the POINT I/O backplane, and it runs on DeviceNet network protocol under the hood. The backplane is a DeviceNet segment. That is why the adapter carries a separate PointBus status indicator next to the network status indicator, and that second indicator is the one people forget to look at when a rack starts dropping modules for no visible reason.

Machine tools are the next place it hides. Okuma and Fanuc controls run DeviceNet between the control and the I/O inside the cabinet, and out to whatever remote I/O the machine has. Screen says DeviceNet error, the alarm book says almost nothing useful, and the spindle is not turning. Then there are MCC lineups with soft starters and drives on drops. One loose joint in one bucket, and a whole section goes unhappy. The bucket that faults is usually not the bucket with the problem.

Two networks, one module. The network indicator watches the DeviceNet trunk outside; the PointBus indicator watches the backplane inside.

Start with the 60 ohm check, not with the scanner

Power down. Network supply and auxiliary supply both. Then put the meter across CAN_H and CAN_L, once in the middle of the trunk and once at each end.

Each end of a DeviceNet trunk gets a 121 ohm resistor, one percent, quarter watt or larger. Two of those in parallel is the entire reason a healthy segment reads what it reads.

Reading across CAN_H and CAN_L	What it means	What to do about it
Under 50 ohms	A third terminator somewhere, a short between CAN_H and CAN_L, or a failed transceiver on a node	Hunt the extra resistor first. Junction boxes, spare taps, the tee somebody added last year
50 to 70 ohms	Normal. Both terminators present, trunk continuous	Move on to the voltage checks
71 to 125 ohms	One terminator missing, or an open in CAN_H or CAN_L	Check both physical ends of the trunk, then walk the joints
Over 125 ohms	No terminator at all on the section you are measuring, or a broken conductor	Terminate the section and measure again

What the meter reads across the data pair on a de-energized DeviceNet segment.

Measuring with the power on gives you a number that means nothing. Same for measuring across a drop instead of the trunk. And that reading up around 121 is worth memorizing, because it is the meter seeing exactly one terminator: either somebody pulled one out, or there is an open between you and the far end of the line.

Five conductors, same signals on every connector style. Red and black carry the 24V, white and blue are the pair you meter.

 

Voltages catch what the resistance check misses

Resistance finds the blunt failures. The faults that come and go for three weeks and then take the line down on second shift are nearly always power distribution or grounding, and those only show themselves with the network energized and loaded.

So load it first. Every node configured for its worst-case draw, outputs on, valve banks energized. Measure a network that is idling and the readings look great right up until production starts.

Check	Normal	Out of range means
V+ to V- at each supply and at both ends of the trunk	11.0 to 25.0V DC	Under 11V the network is out of spec. Under 15V, start looking for a common mode problem. And input devices can quit below 20V even while the network still talks
Largest difference between any two V+ to V- readings	Under 9.3V	Over 9.3V the transceivers will not work properly. Move the supply toward the loaded section, move high-current nodes closer to it, add a second supply, or split the network
V- to shield	Under 4.6V DC	Above 4.6V there is too much current going through the power pair for that length of cable
CAN_H to CAN_L, idle, power on	2.0 to 3.0V	Under 2.0V: an intermittent short to shield or to V-. Over 3.0V: a short to V+, which is where bus off comes from
Shield to earth ground, V- and shield lifted from ground	Above 20 kilohms	1 to 20 kilohms means a second ground path exists. Find it before you do anything else
V- to shield at each end, terminator removed	Under 20 ohms	Higher than that is a broken shield or drain wire in the trunk

Field checks on a live DeviceNet network, and what each reading is telling you.

One more on grounding, because it causes more intermittent faults than bad cable ever did. Shield and V- get bonded to ground at exactly one point, and that point belongs near the physical center of the network. More than one power supply on the segment means tying the V- connections together and bonding them in a single place. Two ground points is how you end up with a network that behaves perfectly until the welder strikes.

The scanner is already telling you which node

Before pulling a single connector, read the node codes on the scanner display. The difference between blinking red and solid red is the difference between one dead node and a dead network, and it costs nothing to look.

Node code on the scanner	What it means	First thing to check
Solid green	Node is allocated by the scanner, running normally	Nothing
Blinking green	Node is not being allocated by the scanner	Scan list entry, scanner not in bus off, connection not timing out
Blinking red	No communication with that node	Power at the node, connection to trunk or drop, baud rate. Code 91 means communication errored out and only clears after cycling the 24V supply
Solid red at power up	Two nodes are sharing one address	Re-address one of them
Solid red at allocation	Bus off	Baud rate first, then the media

Scanner node codes and where each one points.

Three behaviors that waste whole shifts. Pressing the reset button on the scanner does not reset the network. Cycling power to the rack does not reset it either. And cycling network power can push the scanner into bus off by itself, so a restart that makes things look worse does not mean you just broke something.

The mean one is baud rate. A single node set wrong makes other nodes look bad, and I have watched a perfectly healthy node get replaced twice because a neighbor had its rotary switches in the wrong position. If you replace a node that went bus off and the fault stays, stop replacing hardware. At that point it is addressing, baud rate, topology, grounding or noise.

The physical stuff, in the order it actually fails

Loose connections are the number one cause of failures, and after enough panels I would not rank it any lower either. A connection can look perfect and still not be tight. Second on the list is cable stress: bend radius pulled in too tight, a tie wrap crushing the jacket, a trunk draped across a contactor that has been chattering for six years.

Then there is length, which gets blown quietly, one added tee at a time. Every drop line is limited to 6 m (20 ft), and the total of all drops is a separate budget that people forget exists.

Data rate	Thick trunk	Thin trunk	Flat trunk	Single drop	Cumulative drop
125 kbit/s	500 m (1640 ft)	100 m (328 ft)	420 m (1378 ft)	6 m (20 ft)	156 m (512 ft)
250 kbit/s	250 m (820 ft)	100 m (328 ft)	200 m (656 ft)	6 m (20 ft)	78 m (256 ft)
500 kbit/s	100 m (328 ft)	100 m (328 ft)	75 m (246 ft)	6 m (20 ft)	39 m (128 ft)

DeviceNet trunk and drop limits by data rate and cable type.

Keep the cable away from power, welding and servo runs. If the fault only shows up when the robot moves or the welder fires, you already know which tray to go look in, and it is not a wiring mistake anybody is going to find with an ohmmeter.

When a fault refuses to localize, halve the network. Break the trunk near the middle, move a terminator to the break point, power up and see which half comes back. Then split the bad half again. It is slow, it is boring, and it finds the problem, which is more than swapping parts ever does.

Left: where the meter goes on a healthy trunk. Right: the same trunk split at the middle with a second terminator added at the break.

 

For the wiring faults a multimeter is clumsy at, Rockwell points at their own MediaChecker: miswiring, loose connections, opens and shorts. Not a tool every shop owns. On a long segment it earns its keep the first time it saves you from walking two hundred meters of tray twice.

When the trunk measures right and the network still will not come up, this is the next tool out of the bag.

What discontinued actually costs you

The lifecycle entry on the 1747-SDN reads discontinued as of March 31, 2024, with the 5069-AENTR listed against it. Read that entry properly though. The replacement category is engineering replacement, and the 5069-AENTR is an EtherNet/IP adapter. It does not go in the slot. The official path off a 1747-SDN is not a module swap, it is re-networking the machine and remapping every piece of I/O on it.

That is a project with a number attached, and nobody funds it for a line that runs fine. So the practical answer has not changed in years: if the media checks out and the scanner really is dead, put the same catalog number back in and keep running.

The honest exception is worth saying out loud. If the cell is already coming apart for a control system upgrade, do not buy another legacy scanner just to push the migration back another five years. Do it while the panel is open and the money is already approved.

Questions that come up every time

What resistance should a healthy DeviceNet network read?

50 to 70 ohms across CAN_H and CAN_L with the network de-energized. That is two 121 ohm terminators in parallel. Under 50 ohms means an extra terminator or a short across the data pair. Anything from 71 ohms up means a terminator is missing or the trunk is open somewhere between the meter and the far end.

Why does the DeviceNet scanner go bus off after a power cycle?

Cycling network power can drop a scanner into bus off on its own, so that by itself is not proof of a wiring fault. Turn both supplies off, wait ten seconds, bring them back and look again. If it stays in bus off, check baud rate before touching the media.

Can you still buy a DeviceNet scanner for an SLC 500 or a PLC-5?

Not new from Rockwell. The SLC scanner went discontinued in March 2024 and the PLC-5 family has been gone far longer. Surplus and refurbished stock is what keeps these machines running, and for most plants it is the only option that does not turn a bad module into a capital project.

Does POINT I/O really run on DeviceNet?

The backplane does. It is called PointBus, and it runs on DeviceNet network protocol under the hood, which is also why the adapter carries a separate status indicator for it. Worth knowing before you spend an afternoon chasing a rack fault as if it were a bad module.

How do I tell whether a DeviceNet problem is the cable or the node?

Unplug the suspect node and see whether the rest of the network settles down. If it does, put a diagnostic tool on that drop and check whether you can still see the other nodes from there. Still see them, the drop is good and the node is your problem. Cannot see them, it is the drop cable or the tee.

Before you order a replacement

Do the resistance check and the voltage checks first. A good share of what gets pulled and returned as a failed scanner is a media problem that twenty minutes with a meter would have found. When the module genuinely is gone, we keep DeviceNet hardware on the shelf: the 1747-SDN for SLC 500, the 1756-DNB for ControlLogix, the 1769-SDN for CompactLogix and MicroLogix, the 1771-SDN for PLC-5, the 1734-ADN POINT I/O adapter, and the 1788-MCHKR MediaChecker for the days when a multimeter is not enough.