Troubleshooting Devicenet: Marco Bruno - Engineer, Remote Support - 04 - 23. 20

Troubleshooting
DeviceNet
Marco Bruno • Engineer, Remote Support | 04 . 23. 20
PUBLIC
Agenda
1 2 3 4
Media, Verifying Media Troubleshooting Resolving
Installation and Using a Volt/Ohm Using Indicators Common Error
Topology Meter Code Conditions
5 6 7
Troubleshooting Troubleshooting Important
Using RSNetWorx Using Controller Publications and
for DeviceNet Tags Technotes
PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 2

Red +24VDC ( V+ )
White CAN-H
Bare Shield
Blue CAN-L
Black +0VDC ( V- )
• DeviceNet Cable Highlights:

• Comes in Thick, Thin, and Flat (KwikLink) media styles.
• Thick and Thin media contains 5 Conductors 1 pair for 24 Volts DC
power (red and black), 1 pair for signal (blue and white), 1 Shield
(bare).
• Flat media contains only 4 Conductors (minus the Shield).
• Three wire Differential Voltage network communication
accomplished by switching the CANH (WHITE wire) and CANL
(BLUE wire) signals relative to the V- line (BLACK Wire).

95% of all DeviceNet network problems in
the field are media or installation related.

Media-related Issues
• Loose wiring that causes intermittent physical connections.
• Higher voltage cabling ran in parallel with DeviceNet cable.
• Miswiring or frayed wires causing a short.
• Improper conductor stripping.
Physical connectivity issues can cause problems ranging from the loss of
connectivity to a single device to the entire network ceasing to operate.

Installation-related Issues
• The trunk line length is too long with respect to the chosen network baud rate.
• Drop lines on the network are either too long or there is too much accumulated drop length because
of too many individual drops.
• The network was not terminated or grounded properly.
• The network cable was ran in parallel with higher voltage cabling.
• The network was not powered correctly or sufficiently.
Symptoms of installation-related causes can be masked during day-to-day operation and may
only present themselves at a much later date when a change to the network is made.

Verifying Topology
• Any DeviceNet problem where the solution is not immediately
apparent is probably caused by improper initial installation of the
network, a recent topology change and / or a media problem.
• The DeviceNet Planning and Installation Manual (publication DNET-

UM072) includes every topology rule that needs to be followed to create a
properly functioning network.
• Specialized equipment for testing DeviceNet is useful for troubleshooting

topology issues but not necessary. We will focus on what can be
accomplished with only a Volt/Ohm meter.

Verifying Power and Grounding
• The DeviceNet power supplies used must match the ODVA specifications
set in DNET-UM072 (i.e. the supply must have a rise time of less than 250
ms to within 5% of its’ rated output voltage).
• The supply must be sized correctly to provide power to each device

according to its’ requirements. Sometimes this includes said device’s
outputs as well.
• Each device will draw, at minimum, 60 milliamps of current from the

power supply. Some devices will draw more.
• The power supplies must be placed properly to avoid the maximum

allowable common mode voltage.

• On networks with larger trunk lines the placement of the power supply becomes more critical. The
length of the cable will directly affect the ability of the supply to work properly.
• Thick cable has a resistance of 0.0045 Ohms/ft. As the distance from the supply to the powered device
becomes greater, the cable itself becomes a resistor. At any point on the network the Common Mode
Voltage will equal the current being drawn at that point multiplies by the total resistance up to that point.
• V = I x 0.0045 x Distance
• The V+ line will lower its’ voltage gradually from the power supply to the end point of the network. As the V+
line lowers and the V- raises equally. Should this voltage drop become too large the network will fail to
operate properly.
• The CANH and CANL lines are both referenced by the V- line. If the V- line varies more than 4.65 VDC at
any two points on the network all CAN transceivers will fail to operate properly.
• You should never read less than 15 volts across V+ and V- at any point on the network.

• Verify that the ground, the V- conductor, the shield/drain wire are grounded at only one location.
• Verify the grounding has been done at the power supply connection that is closest to the physical center of the
network.
• If more than one power supply is being used, make sure the V+ wire is broken between the supplies.
• All grounding and ground wire specifications can be found in DNET-072.

Verifying Network Grounding
1. Turn off all network power supplies.
2. Disconnect V- and Shield wires are from earth ground and from each
other.
3. Measure and record the DC resistance between Shield and earth ground
at the furthest ends of the network.
4. Connect the V- and Shield wires to earth ground.
If the measured values are < 1 M Ohm…
• Check for additional grounded V- or Shield wires.
If the measured values are > 1 M Ohm…

Common Mode Voltage Check
1. Turn all network power supplies on.
2. Configure all nodes for their maximum current draw from network power.
For example, turn on all outputs that use network power.
3. Measure and record DC voltage between V+ and V- where each power

supply connects to the trunk.
4. Measure and record DC voltage between V+ and V- at the ends of the

network.

Common Mode Voltage Check
If the difference between any two measured values is < 9.3 Volts…
If the difference between any two measured values is > 9.3 Volts…
The Network will not operate properly. Possible solutions are:
• Shorten overall length of the network cable.
• Move power supply in direction of overloaded section.
• Move nodes from overloaded section to less loaded section.
• Move high current loads close to the power supply.
• Add a second power supply.
• Break the network into two separate networks.

Verifying Spacing from AC Voltage
DeviceNet is a Category 2 network and must adhere to the following spacing guidelines
from publication 1770-4.1 (Industrial Automation Wiring and Grounding Guidelines):

Verifying Trunk Length
• The trunk line is the longest length of cable between the furthest two points on the
network.
• The legal trunk line length varies by the selected baud rate and cable type.
• The reason cable type matters is that thinner cables cause more resistance and a
higher voltage drop across the length of the network.
• Higher baud rates require a cleaner base environment with the fewest packet errors.

Verifying Drop Length
• Drop lines are permitted to be branching and daisy-chained.
• No matter what type of drop is used, the cumulative length of the cable in a single drop cannot be
longer than 20 ft.

Verifying Cumulative Drop Length
• The maximum total length of all drop lanes varies by baud rate and cannot be
exceeded.
• As previously explained the importance of these specifications is to provide the
best initial baseline for the network.

Verifying Termination
• Termination is used to match the impedance of a node to the impedance of the transmission
line being used.
• When impedances are mismatched, the transmitted signal is not completely absorbed by the
load and a portion is reflected back into the transmission line.
• If the source, transmission line and load impedance are equal, these reflections are
eliminated. This is critical to proper network operation.

• There should only be two terminators, 120 or 121 Ohms, ¼ Watt or greater.
• The proper location of the termination resistors is at the very beginning and the
very end of the trunk line.

1. Turn all network power supplies off.
2. Measure and record DC resistance between WHITE (CANH) and BLUE (CANL) wires at the
middle and end of the network.

If you measure < 50 ohms…
• Check for more than two terminating resistors, there are probably at least
three.
• Check for a short-circuit between WHITE (CANH) and BLUE (CANL).
• Check nodes for faulty transceivers (we’ll discuss this shortly).

If you measure 60 ohms…
If you measure 71 – 121 ohms…
• Check for open circuits in WHITE (CANH) or BLUE (CANL).
• Make sure there are two properly wired terminators instead of only one.

Resolving Termination Issues
1. Split the network down the middle into two segments.
2. Check resistance of each segment - should be 121 Ohms since only a single terminating resistor is present on each segment.
3. Mark a break point and leave it disconnected. At least one segment will show resistance = to 121 Ohm.
4. Split a bad segment into two sections and add, temporarily, a terminating resistor to the non-terminated section. Mark the location of the break
point and temporary terminating resistor.
5. Check the resistance of each section - should be 121 Ohm.
6. Continue splitting the network until the problem is located and repaired.
7. Remove all temporary resistors and bring network back to original state.
8. Verify once again that the assembled network has 60 Ohm resistance.

CAN Line Voltage Check
• Each node contains a CAN transceiver that generates differential signals onto the data conductors.
• When the network communication is idle, the CANH and CANL voltages are approximately 2.5 volts.
• Faulty transceivers can cause the idle voltages to vary and disrupt network communication.
• Although this test indicates that faulty transceivers may exist on a network, it will not indicate which node has the
faulty transceiver. If a node with a faulty transceiver is suspected, perform a CAN transceiver resistance test.

1. Turn all network power supplies on.
2. Configure all nodes for their maximum current draw from network power / Turn on all outputs that use network
power.
3. Measure and record DC voltage between V+ and V- where each power supply connects to the trunk.
4. Measure and record DC voltage between V+ and V- at the ends of the network.

If CANH and/or CANL measures < 2.0 Volts…
CANH/CANL conductor has intermittent short to shield or V-, or possibly a faulty transceiver on one or more nodes.
 Check all open style and field wireable connectors.

 Check CANH and CANL conductors for continuity.
 Perform transceiver test on suspect node(s).
If CANH and/or CANL measures 2.0 – 3.0 Volts…

If CANH and/or CANL measures > 3.0 Volts…
CANH/CANL has intermittent short to V+. Network most likely in Bus-Off state.
• Check all open style and field-wireable connectors.

• Check for excessive common mode voltage.

CAN Transceiver Check
The CAN transceivers used in DeviceNet nodes have one circuit that controls CANH and another circuit that controls
CANL. Electrical damage to one or both circuits may increase the leakage current in these circuits.

1. Disconnect the node from the network. Leave the node unpowered.
2. Measure and record the DC resistance between CANH and V-.
3. Measure and record the DC resistance between CANH and V+.
4. Measure and record the DC resistance between CANL and V-.
5. Measure and record the DC resistance between CANL and V+.

If the measured values are < 1 M Ohms…
You have a faulty CAN transceiver.
If the measured values are between 4M to 6M Ohms…
If the measured values are > 6 M Ohms…
You have a faulty CAN transceiver.

Troubleshooting Using Indicators
Device LEDs and what they tell us:
All DeviceNet devices whether they are Scanners or slaves, first or third
party, share the same LED scheme and the signals can be interpreted in the
same way.
The LEDs that are most common to DeviceNet troubleshooting are the
Module (or “MOD”) and Network (or “NET”) LEDs. Some devices combine
these two LEDs into one.
• The Module LED indicates the health of the module in question.
• The Network LED indicates the state of the relationship to the

network the module in question has.
Most DeviceNet Scanner modules also have an alphanumeric or seven-

segment LED display which show error codes and node address numbers.

Device LEDs and what they tell us, cont…
MODULE LED
LED Description
SOLID GREEN The device is operating normally.
FLASHING GREEN The device has no faults but is in an idle state. It may
have no connection to a master or may not be
configured.
SOLID RED Unrecoverable fault. The device has probably
experienced hardware failure. If the device is operable
it will certainly require a power cycle to regain
operation.
FLASHING RED The device has a recoverable fault. Deeper analysis is
required.
OFF The device likely has no power.
ALTERNATING RED/GREEN This is purely device-dependent.

Scanner LEDs and what they tell us:
Network LED
LED Description
SOLID GREEN The device is operating normally and, if it is a slave
device, has a connection made with its’ master.
FLASHING GREEN If the device is a master, it is in an idle state and will
not write outputs. If it is a slave, it has a good network
connection but no connection to a master.
SOLID RED Duplicate node failure or BUS OFF condition. There is
another device on the network that is already
occupying the same node address this device is trying
to use. Or, a Bus Off condition has occurred in which at
minimum a power cycle will be required for the device
to become operational.
FLASHING RED Some devices will do this if the connection to the
master is lost during operation.
OFF The device likely has no power.

Scanner LEDs and what they tell us, cont…
7 SEGMENT LED AND ALPHANUMERIC DISPLAYS

• These displays exist only on Scanners and display information pertaining to
either the network, the Scanner itself or the devices under its’ control.
Devices not in its’ scanlist are not accounted for.
• The Scanner’s display will show only one number at a time. If necessary, the
number will change in one second intervals. The scanner will show all of its’
error information then repeat indefinitely.
• The number shown will either be an error code or a node address.
• Remember that node addresses are 00 – 63, there are no error codes in this
range.
• The Scanner will always show the node address followed by the
status/error code. This is critical to understand when troubleshooting as
there may be several errors present on several nodes.
• The Scanner will also show its’ own status. If all is normal with the Scanner and
the network, the scanner will show its’ own node address and nothing else.

Most Common Scanner Status/Error Codes:
• 80 - Scanner is in IDLE mode. (1756-DNB shows “IDLE”)

• 78 - Device is in scanlist but is not present on the network (slave node timeout)
• 77 - Data size specified in scanlist doesn’t match slave node’s configuration.
• 73 - Slave node on network doesn’t match device identity in scanlist (key
mismatch).
• 92 - The scanner is on but there is no DeviceNet network power present. (1756-
DNB shows “No Network Power”)
• 91 - Scanner is BUS OFF. (1756-DNB shows “Bus Off Detected”)
• 70 - Scanner has a duplicate node address. (1756-DNB shows “Duplicate Node
Address”)
• 79 - Scanner cannot transmit. (1756-DNB shows “NoTx”)

Scanner Display Information
• The scanner will display one number at a time, in rotation, in one-second intervals.
• The scanner will display the errors in the order of lowest node address to highest
but will show its’ own status first.
• The scanner will show the node address of the affected node then the error code.
00 – 80 – 01 – 78 – 02 – 77 – 05 – 78 – 10 – 73 – 00 - 80

00 – 80 – 01 – 78 – 02 – 77 – 05 – 78 – 10 – 73 – 00 - 80
The scanner’s node address is 00 and it is in IDLE mode.
In all cases error code 80 only refers to the scanner itself.

00 – 80 – 01 – 78 – 02 – 77 – 05 – 78 – 10 – 73 – 00 - 80
The connection with the slave device at node 01 has timed out.

00 – 80 – 01 – 78 – 02 – 77 – 05 – 78 – 10 – 73 – 00 - 80
The connection size specified in the scanlist does not match the way node 02 is configured.

00 – 80 – 01 – 78 – 02 – 77 – 05 – 78 – 10 – 73 – 00 - 80
The connection with the slave device at node 05 has timed out.

00 – 80 – 01 – 78 – 02 – 77 – 05 – 78 – 10 – 73 – 00 - 80
There is an identity key mismatch, node 10 does not match its’ Scanlist entry.

00 – 80 – 01 – 78 – 02 – 77 – 05 – 78 – 10 – 73 – 00 - 80
The error codes are repeating, this is the beginning of a new cycle.

Error Code 77 Resolution
The input and output sizes specified
in the slave node’s configuration are
checked by the Scanner when
making a connection to the device.
If these sizes do not match the
connection is refused.

In many cases the device’s configuration can
be viewed in RSNetWorx and the values in the
Scanner’s “Edit I/O Parameters” window can be
corrected accordingly.
Remember that the Input Size is the slave’s

Produced data. Output is Consumed by the
slave.
Once the proper values are entered here the

device will need to be re-mapped, likely
necessitating ladder logic changes.
Once the numbers in this window match the

requirements of the slave node the 77 error will
clear.

If the slave node’s I/O sizes are unknown the
device can be interrogated via explicit
messaging. This can be done with RSNetWorx
by using the Class Instance Editor.
The Class value is always 5.
The Instance in our example is 4 indicating we

are looking for the COS size. We would use 2
if looking for Polled.
The Attribute value is 7 for the device’s Input

size, 8 for the Output size.
Check the “Data received from the device” field

after clicking Execute.

• The Explicit Messaging method for finding the device’s I/O size will not always work because
some devices are not fully ODVA-compliant. Even if it does work, the data may not actually be
helpful depending on the situation.
• If a device has variable I/O sizes the “correct” I/O size would be the one that fits the application.
Simply correcting the 77 error may not be the entire solution if the sizes being used don’t work for
how the device is intended to be used.
• There may be no way to know what the device’s I/O size is without its’ documentation.
• RSNetWorx grabs default sizes for a device from the device’s EDS file when you add it to the
Scanlist. If the device is configured in a way other than the default, these sizes will not work
• Some device’s I/O sizes may not be configurable via its’ Parameters in RSNetWorx, they could
be configured via hardware (DIP/rotary switches, etc.).
• It’s always possible the device itself is configured correctly but the Scanlist is not – or vice-versa.

This error is typically seen after starting up a network created with an off-
line RSNetWorx configuration or after replacing an existing device on a
working network.
The Scanner checks the identity of a device when attempting to open a

connection with it. A failure of this identity check causes the 73 error.
The scanner will scan all identity information selected for a device in the
Scanlist configuration. In this example a 1799-ZCIO module has every key
selected except for the Major Revision.
In this case, a 1799-ZCIO could be connected to the network at node 33

and be any firmware revision without a key mismatch. All other keys must
match.

Accessing the Scanlist when a key mismatch is present will automatically present the user with set of
options to resolve the problem.
Update Key will keep the Scanlist entry the same but will make the
new key information the “true” keys for the device. This is ideal if the
only difference between the new and old device is a firmware change
and the device’s configuration is or will be exactly the same.
Remove from Scanlist will make room for the new device to be added
at the same node address as the old one and for the mapping to
be replaced. This is necessary if the old and new devices have a
different I/O configuration or are completely different types of devices
as seen in this example.
Ignore will cause the software to take no action.

Error Code 72/78 Resolution
Both of these error codes indicate that the Scanner cannot communicate with a device that is
in its’ Scanlist.
The difference in these error codes is when the Scanner detects the timeout.
72 indicates the slave node has timed out during operation and had a good connection
made with the Scanner at some point since the network was powered up.
78 indicates the slave node was not present when the network was
powered up.
The time the Scanner waits for a Polled response to time out is
determined by its’ Expected Packet Rate setting, configured in
RSNetWorx. The default is 75, is unitless, and is multiplied by 4
to get the timeout in milliseconds (300 ms).

Error Code 72/78 Resolution
There are several reasons for these errors to occur and no single approach to take for a resolution.
The issue could be as simple as an inadvertently disconnected or powered-down device to

something as complex as a non-ODVA conforming device that has difficulty with answering the
Scanner’s polls at the default Expected Packet Rate.
If the slave device in question is verified to be properly connected to the network then its’ LED
status should be checked:
• A flashing green NET LED indicates the device has a good connection to the network but not to
the Scanner. It’s possible the device is set to the wrong node address.
• A flashing red NET LED indicates a duplicate node address.
• A solid red NET LED could indicate a CAN chip malfunction or the wrong baud rate has been
selected on that device.

Error Code 79/NoTx Resolution
• A 79 error (or NoTx error on a 1756-DNB) will supersede any other
errors that may be present.
• The DeviceNet will not operate at all while this error is present.
• The error is indicating a condition where the Scanner senses network

power (24V on V+ and V-) but detects either no signal or a foreign
signal on the CAN lines (CANH and CANL).
• A flat signal could be caused by improper wiring or a break in the

CAN lines somewhere on the network not allowing a proper loop to
be formed through the termination resistors. This can be verified by
performing a termination test for 60 ohms.
• Verify that the scanner’s baud rate is correct otherwise the signal it
detects on the CAN lines will be considered invalid.

Error Code 75/NoRx Resolution
A 75 error (or NoRx on a 1756-DNB) almost always indicates there is no
Scanlist present in the Scanner.
A Scanner that has just been taken out of the box will alternate between
63 and 75, indicating its’ default node address of 63 and no Scanlist
present.
A 1756-DNB would display A#63 and NoRx.
In very rare cases this error can indicate a very specific condition:
Every node in the Scanlist is not present on the network AND there is at
least one other device present on the network that is not present in the
Scanlist. This provides good traffic for the Scanner to detect on the
network but no valid slaves for the Scanner to connect to. This may be
caused by some devices on the network being at the wrong baud rate
while others are at the correct baud rate.

Error Code 80/IDLE Resolution
In the IDLE state the Scanner does actively poll devices and read inputs
but it will not write outputs
This is the default state of the Scanner and requires programmed action
in order to enter RUN mode.
The precise way this will be done depends on the type of Scanner being
used. With the 1756-DNB you must programmatically turn on the bit in
a Boolean tag in the 1756-DNB’s CommandRegister tag group.

This error means the Scanner itself has detected a duplicate node address.
Either the Scanner’s or the offending node’s address will need to be changed so
that all devices have a unique address.
There are several ways this could be done depending on the device types
involved. Hardware and / or software methods are available. Refer to the
device’s documentation for exact instructions.

Error Code 91 / Bus Off Resolution
• The DeviceNet scanner has an internal error counter that increments with each “bad” packet
received and decrements with each “good” packet.
• Bad packets are corrupt, malformed and/or otherwise did not pass a CRC check.
• Once the count reaches a certain number the network traffic is deemed to be corrupt overall
and all reading of inputs and writing of outputs stops and the scanner displays “91” or “Bus
Off Detected”.
• A network reset is required to continue after a Bus Off condition. This can be done most
effectively by cycling the 24V DeviceNet power on V+ and V- followed by a reset of the
Scanner via its’ Command Register or by cycling chassis power.
• After the reset, if the condition that brought on the condition was not corrected, the bad
packet count will rise again and the Bus Off condition will return.

The cause of a Bus Off condition could be anything that causes malformed packets:
• A network that was not installed properly with respect to topology specifications will not have a solid baseline, or
foundation, to build from. Even if the network works properly at first, a later (even years later) addition or change to the
network or environment could cause an imbalance leading to a Bus Off.
• Over time, temperature changes and/or abuse of network cabling can cause loose, intermittent connections.
• A short in the cabling such as V- to CANL will cause an immediate Bus Off with no discernible build up. Cycling power
will not clear the error, the Scanner will immediately go Bus Off after power up.
• Network cable that is too close to high voltage or other sources of noise, such as welding or other maintenance taking
place nearby, can cause a Bus Off. It could be immediate or over time.
• Mismatched baud rates on networked devices.
• The Scanner or other networked devices having a bad connector, internal short or otherwise compromised CAN chip.

Determining the cause of a Bus Off:
Does the Bus Off happen immediately or over time?
Immediate:
1. Verify all devices are at the same baud rate.
2. Check for shorts.
3. Check for problematic nodes by removing one node at a time and cycling network power.
4. Disconnect CANH and CANL from Scanner and verify that it shows NoTx or 79. If it still shows
Bus Off or 91 it must be replaced.
5. Move on to “Bus Off happens over time” troubleshooting steps.

Determining the cause of a Bus Off:
Does the Bus Off happen immediately or over time?
Over time:
1. “Wiggle test” all connectors to check for intermittent open conditions.
2. Verify all aspects of topology are correct; that the network has been properly installed, powered
and grounded.
3. Verify that no sources of electrical noise are in close proximity to the network cabling.
4. Move on to “Bus Off happens immediately” troubleshooting steps.

Troubleshooting with RSNetWorx for DeviceNet
Interpreting RSNetWorx Symbology
• The 1738-ADN18 shown above has failed one or more identity key checks. It could be that there actually is a
physical 1738-ADN18P on the network but it is at a different firmware revision than the one in the project. It’s
also possible that it is a completely different device.
• The 1747-SDN exists in the project but RSNetWorx could not find a physical 1747-SDN on the network at node
2. In fact, it could find no device at all that would respond to an identity check directed at node 2. If there is a
physical 1747-SDN on the network it is likely not at the same node address shown in the project file.
• It’s important to note that some devices will not respond to a browse request while they are communicating to
their Scanner. This does not indicate a problem with the device.

RSNetWorx Diagnostics / Network Health Monitor
• The Network Health Monitor allows you to view all detectable network problems in one location and the software
can give troubleshooting tips on individual issues.
• This method of troubleshooting is most useful if you are working remotely and have no way of viewing a device’s
LED status.
The errors are

presented in a
branching trunk
fashion. An error
seen on the trunk
indicates a problem
(or multiple problems)
to locate in a branch
below.

RSNetWorx Diagnostics / Network Health Monitor
• The Network Health Monitor allows you to view all detectable network problems in one location and the software
can give troubleshooting tips on individual issues.
• This method of troubleshooting is most useful if you are working remotely and have no way of viewing a device’s
LED status.

Troubleshooting Using Scanner Status Registers/Tags
• All of the Scanner’s diagnostics are kept in the
controller and updated automatically.
• These are meant to be used to programmatically

respond to changing network conditions, for
alarming purposes and for remote displaying and
viewing of status. They can be useful for
troubleshooting, particularly if the Scanner is in an
inconvenient location.
• The 1756-DNB’s Input StatusRegister tags provide

very basic information.
• The StausRegister.Run bit will be On if the DNB is

in RUN mode, Off if it is currently IDLE.
• The StatusRegister:DeviceFailure tag indicates a

wide range of problems with any node in a single bit.

The 1756-DNB’s Status tag group (S) gives very detailed and explicit error information.

• The DeviceFailureRegister consists of 64 bits, each representing nodes 0 – 63.
• If a node isn’t communicating its’ bit will be high, low indicates normal operation or that node is not present in the
scanlist. The specific error is not shown here.
• The Scanner’s node address bit will be high if any error is present.
Node 0
Node 10
Node 17

• The StatusDisplay tags mimic the 1756-DNB’s alphanumeric LED display using ASCII..
A 1756-DNB in IDLE mode’s

StatusDisplay tags will alternate
between A#00 and IDLE in the
same 1 second intervals as the
DNB’s physical display.

• The ScanneAddress and ScannerStatus tags show the DNB’s own current address and state.
• The ScrollingDevice tags will constantly change and update, scrolling through each node that has an error to report.
The ScannerAddress and Status tags are showing us the DNB’s node address is 0 and
it is in IDLE mode (80).
The ScrollingDeviceAddress and Status tags are showing us node 17 has an 83 error,
which means node 17 is present in another scanner’s scanlist, which is an illegal
configuration.

• If there is a specific node you want to monitor the DeviceStatus tags can be useful.
• Each node has its’ own SINT tag that constantly shows its’ current error condition.
Node 0 is DeviceStatus[0] which is

the 1756-DNB. It is in IDLE mode,
indicated by “80”.
Nodes with a status of “0” are not

present in the scanlist.
Nodes 10 and 17 are present in

this scanlist but are also present
in another Scanner’s scanlist, as
indicated by error code 83. This is
an illegal configuration.

Important Publications and Technotes
• DeviceNet Scanner Error Codes – 38655
• DeviceNet Bus-Off Error 91 Causes and Troubleshooting – 26046
• Troubleshooting a DeviceNet Network – 15075
• Location and how to Ground DeviceNet Media – 20623
• Troubleshooting Error 77: I/O Size Mismatch on DeviceNet – 24919
• DeviceNet Network: Error E73 Identity Information Mismatch – 42511
• DeviceNet Book of Knowledge 01/22/2103 Edition – 44883
• DeviceNet Error Code 78 – 452055

Important Publications and Technotes
• DeviceNet Media Design and Installation Guide – DNET-UM072
• DeviceNet Network Configuration User Manual – DNET-UM004
• 1756-DNB Installation Instructions - 1756-IN566
• 1747-SDN User Manual - 1747-UM655
• 1769-SDN User Manual – 1769-UM009
• 1771-SDN User Manual - 1771-UM118
• 1788-EN2DNR User Manual – 1788-UM059

Thank you / Q & A
www.rockwellautomation.com

Troubleshooting Devicenet: Marco Bruno - Engineer, Remote Support - 04 - 23. 20

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting Devicenet: Marco Bruno - Engineer, Remote Support - 04 - 23. 20

Uploaded by

Copyright:

Available Formats

Troubleshooting

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 2

• DeviceNet Cable Highlights:

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 3

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 4

• Higher voltage cabling ran in parallel with DeviceNet cable.

• Miswiring or frayed wires causing a short.

• Improper conductor stripping.

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 5

• The network was not terminated or grounded properly.

• The network was not powered correctly or sufficiently.

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 6

• The DeviceNet Planning and Installation Manual (publication DNET-

• Specialized equipment for testing DeviceNet is useful for troubleshooting

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 7

• The supply must be sized correctly to provide power to each device

• Each device will draw, at minimum, 60 milliamps of current from the

• The power supplies must be placed properly to avoid the maximum

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 8

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 9

• All grounding and ground wire specifications can be found in DNET-072.

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 10

If the measured values are < 1 M Ohm…

• Check for additional grounded V- or Shield wires.

If the measured values are > 1 M Ohm…

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 11

3. Measure and record DC voltage between V+ and V- where each power

4. Measure and record DC voltage between V+ and V- at the ends of the

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 12

The Network will not operate properly. Possible solutions are:

• Shorten overall length of the network cable.

• Move power supply in direction of overloaded section.

• Move nodes from overloaded section to less loaded section.

• Move high current loads close to the power supply.

• Add a second power supply.

• Break the network into two separate networks.

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 13

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 14

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 15

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 16

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 17

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 18

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 19

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 21

• Check for a short-circuit between WHITE (CANH) and BLUE (CANL).

• Check nodes for faulty transceivers (we’ll discuss this shortly).

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 22

If you measure 71 – 121 ohms…

• Check for open circuits in WHITE (CANH) or BLUE (CANL).

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 23

5. Check the resistance of each section - should be 121 Ohm.

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 24

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 25

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 26

 Check all open style and field wireable connectors.

If CANH and/or CANL measures 2.0 – 3.0 Volts…

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 27

• Check all open style and field-wireable connectors.

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 28

PUBLIC | Copyright ©2020 Rockwell Automation, Inc. | 29

2. Measure and record the DC resistance between CANH and V-.

3. Measure and record the DC resistance between CANH and V+.

4. Measure and record the DC resistance between CANL and V-.