Network Troubleshooting

Presented by:
Gordon MacLachlan (Mac)
 Presentation Highlights
‹ Troubleshooting tools that work
‹ Common wiring problems

‹ Common networking problems

‹ Common communication problems

‹ Common configuration problems

‹ Common data transfer problems

Typical network commissioning
process:
1. Install the equipment
2. Wire up the networks
3. Configure equipment
4. Establish communication
links between equipment
5. Check communication
quality
6. Check data transfer
What’s in your toolbox?
Troubleshooting tools that work:

Essentials:
‹ Multimeter

‹ RS-232 Tester (Breakout box)

‹ Cell phone

‹ Internet

‹ Ethernet Crossover cable

‹ Serial capture utility

‹ Ethernet capture utility

Also useful:
‹ Hub

‹ Oscilloscope (for noisy networks).

Common Wiring Problems
RS-232:
‹ Receive/Transmit Polarity
‹ Ground potential differences.

‹ DTR/DSR and CTS/RTS issues

‹ Cable Length
Common Wiring Problems
RS-232 Receive/Transmit Polarity:

‹ Best way to check Polarity is to use a RS-232 Test box

(FieldServer supplies a mini-tester)
• With no communications, RD must be on solid.
• If the same light is on solid (RD or TD) when either side of
the test box is connected on its own, then the polarity is
wrong.
‹ A Voltmeter can be used to check a devices pins when it is
disconnected. Receive will have a zero voltage, Transmit will
have a negative voltage of -5to-12V (wrt ground).
‹ Remember: Rx goes to Tx, and vice versa
 Common Wiring Problems
RS-232 ground potential differences:

‹ Since signal ground is connected through the

GND pin, any serious potential differences
between the two devices can cause
communications problems or even interfere
with the operation of the device.
‹ In the rare cases where this is genuinely a
problem, use an optical isolator to separate
the wiring. Optical Isolators
are off-the-shelf items
that can be purchased online.
Common Wiring Problems
RS-232 DTR/DSR and CTS/RTS issues:

‹ NB: FieldServer does not

require DTR/DSR or CTS/RTS
handshaking lines. FieldServer
needs Tx/Rx/GND only.
‹ The device connecting to the
FieldServer may need
handshaking. Solve this by
bridging CTS to RTS (and/or
DTR to DSR) in the connector
connected to the device.
Common Wiring Problems
RS-232 Cable Length:

‹ Maximum recommended cable

length for RS-232 is 50ft. This is
conservative if you are using
18 AWG.
‹ Symptoms for cable length problems
are that communications is noisy. It
is unlikely that a cable that is a
bit too long will prevent
communications completely.
Common Wiring Problems
RS-485:
‹ +/- Polarity
‹ Line Biasing.

‹ 4-wire vs. 2-wire

‹ Cable Length
Common Wiring Problems
RS-485 Polarity:

‹ Unlike RS-232 where Tx and Rx cross

over, you connect + to +, and – to – in
RS-485
‹ Some devices use A and B instead of +
and – labels. Here A is the same as -, and
B is the same as +
Common Wiring Problems
RS-485 Line Biasing:

‹ Literature on RS-485 guidelines

advises that 120 ohm terminating
resistors are applied at the end
nodes of an RS-485 segment. This
is a guideline, and not a rule.
‹ Networks <100 feet usually don’t need
terminating resistors.
‹ Line Biasing is achieved with the 120 ohm
resistors plus 10kOhm resistors between
the signal and ground/5V.
 Common Wiring Problems
RS-485 4-wire vs. 2-wire:
‹ FieldServer supports 2-wire RS-485 communications, which
is half duplex RS-485 and is the more common format found
in industry.
‹ 4-wire RS-485 (or RS-422) is full duplex RS-485. Some 4-
wire RS-485 will allow you to connect to a 2-wire RS-485
setup by bridging the Rx and Tx lines to make 2 wires out of
4. These devices tolerate the visibility of Tx signals on their
Rx lines. However, other 4-wire devices do not tolerate this.
‹ It is always possible to connect 2-wire to 4-wire RS-485 by
using a 2-4 wire RS-485 converter which is commercially
available.
Common Wiring Problems
RS-485 Cable Length:

‹ Recommended maximum length

is 4000 ft, with no more than 32
nodes connected. This estimate is
for the most part optimistic.
‹ Many factors can reduce the
maximum permissible length on
an RS-485 network, including
wire gauge, installation
environment, and vendor
equipment characteristics.
‹ When running cable lengths close
to the recommended maximum
parameters, keep an RS-485
repeater handy just in case…
Common Wiring Problems
Ethernet:
‹ Cable quality
‹ Direct vs. Crossover.
 Common Wiring Problems
Ethernet Cable Quality:

‹ Most common Ethernet cable in

use today is CAT-5 UDP cable.
‹ Using CAT-5 UDP has many
advantages, but the one common problem
experienced is assembly quality. Factory
made cables are usually pre-tested and
tend to work, but cable crimped on site
often leads to problems that are not
immediately obvious.
 Common Wiring Problems
Ethernet Direct Cable vs. Crossover cable:
‹ Use Direct Cable when
connecting to a hub
‹ Use Crossover cable when
connecting directly between
two devices
‹ Cables can be differentiated by
looking at the connectors on
each end of the cable. Hold
them together, facing the
same way (e.g.: both clips
facing away from you). If the
wire colors follow the same
pattern on both connectors,
then it is a direct cable.
Common Networking Problems
RS-232 & RS-485:

‹ Baud Rate
‹ Master vs. Slave.

‹ Handshaking

‹ Addressing

‹ Poll timing
Common Networking Problems
RS-232 & RS-485:
‹ Baud Rate
• Don’t just check Baud Rate. Check Parity, Data Bits and
Stop bits too.
• All devices on the same RS-485 network need to
communicate at the same baud rate. Make sure this is
possible.
‹ Master vs. Slave.
• For Master/Slave networks (e.g.: Modbus, Metasys), one
Master usually controls all communications
• Make sure you know who is master, and that you are not
attempting Master-Master or Slave-Slave communications.
 Common Networking Problems
RS-232 & RS-485:
‹ Handshaking
• Some
devices/protocols
demand startup
handshaking like the
passing of passwords
and device
information.
• Check literature for
requirements and
default passwords.
Common Networking Problems
RS-232 & RS-485:

‹ Addressing
• Make sure the correct device
address is being used. This is not
always obvious (e.g.: BACnet
MSTP)
• Server devices almost always need
addresses, but sometimes you need
to configure client addresses too
(e.g.: DNP 3.0)
• Some protocols may demand
address paths or addresses at
multiple levels (e.g.: Modbus +,
McQuay)
 Common Networking Problems
RS-232 & RS-485:
‹ Poll timing
• Timing can be a very complicated issue and is
not uncommon as a cause for poor
communications
• There are many timing factors to be aware of
in a communications session (e.g.: Timeouts,
poll delay, retry intervals, scan intervals,
probation delays, Inter character timing, etc)
• Enote067 is very helpful in
helping understand how
these parameters interact
• Symptoms of a timing
problem are usually
related to the presence
of partial communications
Common Networking Problems
Ethernet:
‹ Subnets and gateways
‹ Firewalls.

‹ Ports

‹ Addressing
Common Networking Problems
Ethernet:
‹ Subnets and gateways
• A common problem in Ethernet is that IP
addresses get set up correctly without
the subnets and/or gateway addresses
being set up correctly
• Protocols differ in their
IP/Subnet/gateway
requirements, so be
aware of the
requirements for the
separate protocols.
Common Networking Problems
Ethernet:

‹ Firewalls.
• The thing about firewalls
are that they are invisible
to the installer, but can
stop communications in a
heartbeat
• Work with the Systems
Administrator to ensure
that all necessary holes are
made in the firewalls for
the application, and that
the network design is
compatible with the
company’s security policies.
 Common Networking Problems
Ethernet:
‹ Ports
• Be aware that Ethernet protocols have ports too.
However, they are logical, not physical. Be aware of the
port required for a given protocol, you may need to
open a hole in a firewall for that port.
‹ Addressing
• Not all Ethernet protocols use IP addresses for
addressing. Look out for the need to use multiple or
indirect addresses (e.g.: BACnet IP,
Modbus/TCP),
or even MAC addresses
(e.g.: BACnet Ethernet)
Common Networking Problems
Ethernet:

‹ System Administration
• When adding devices to an
existing network, be aware
that this cannot be done
without knowledge of what
exists on the network.
• When doing a new network,
leave a good document trail
of how the network has
been configured.
• Be aware of the issues that
come with mixing DHCP
and fixed addressing
• Ignore the above, and you
can expect a return trip to
site.
Common Communication
Problems
‹ Transmitting polls, but get
no response (Timeouts)
‹ Received Data is rejected

‹ Communication stops

‹ Communication exists with errors.

Checking communications
quality using Ruinet (RUI):
1. Check Connection Overview for
communication errors
2. Check System Error screen for
System/Config errors (Messages are OK)
3. Check Node & Map Descriptor overviews
for missing Nodes/Map descriptors
4. Check Data Array overview for data
update
 Common Communication
Problems
‹ Transmitting polls, but get no response
(Timeouts)
• This is the most common communication level
symptom.
• Cause is usually related to Installation or Network
setup errors, so review the previous slides.
• Cause can manifest itself at any level
though, so finding the cause can
take time. Make use of all visual
symptoms (TX/Rx LED’s, wiring, etc)
to reduce the range of possible
causes.
 Common Communication
Problems
‹ Received Data is rejected
• The symptoms for this range from
no response from the remote
device, to a defined negative
response.
• There are several reasons why a poll is
rejected, based upon either a corrupted
message to incorrect parameters in a poll.
• Corruption is caused by timing issues or poor
installation.
• Timing corrupts the messages when they
are not delivered within the correct
timing parameters.
 Common Communication
Problems
‹ Communication stops
• This is a very unusual
symptom, but hard to nail
down when it occurs
(Mainly due to the fact that
the behavior is erratic)
• Stopped communication is
usually caused by
something event driven.
Work towards identifying
the event in order to
expedite finding the cause.
Common Communication
Problems
‹ Communication exists with
errors.
• Partial communications could be
related to many devices on the
network, and only some not
communicating, or maybe even
some addresses on a device that
are bad. Use the Hierarchical tiers
in Ruinet to resolve this.
• Another cause for partial
communications is poor quality
installation. If the same address
poll succeeds only some of the
time, this is most likely related to
installation or timing.
Common Configuration
Problems
‹ Client vs. Server mapping (wrong
function)
‹ Responsible Map Descriptor

management
‹ Missing titles

‹ Client/Server node matching

‹ Duplicate names and/or addresses

‹ Address range gaps

Common Configuration
Problems
‹ Client vs. Server mapping (wrong
function)
• Restated, this problem occurs most
commonly when no active
communication devices are configured,
or two active communication devices are
configured when only one is allowed.
‹ Responsible Map Descriptor
management
• Active FieldServer mappings monitor the
status of communication to determine
the health of the corresponding data
array value/s
• Consequently it is not possible to have 2
active mappings pointing to the same
data array offset/s.
Common Configuration
Problems
‹ Missing titles
• Configuration layout can be quite flexible, but one must
take care with the titles (Title, Nodes, Connections,
Moves, Data Arrays, etc)
• The FieldServer searches for the titles to know where to
find the corresponding keywords and parameters, so the
titles must be there.
‹ Client/Server node matching
• Node ID specified in the Node_ID field is almost always
the device address of the server or the passive
communications device. This MUST be right for
communications to occur.
• “Nodeless” protocols do exist. By nature, these are point
to point protocols where only one device is allowed to be
connected to any port.
Common Configuration
Problems
‹ Duplicate names and/or addresses
• Duplicates can be hard to find and are sure to
cause problems.
• One symptom to look for is individual
addresses not working when everything else is
working.
Common Configuration Problems
‹ Address range gaps
• Be careful polling a device that
documents gaps in the addressing
system. Don’t assume the addresses
are still there.
• Polling a range of addresses containing a
gap within the range will likely result in
nothing being returned.
• Make a habit of providing “zero data” for
unused addresses so when polled by a
block that includes unused addresses,
FieldServer still responds.
• When serving data on FieldServer, it will
not combine two map descriptors to
satisfy an incoming poll for data, so one
map descriptor must exist that covers the
full range of the polled data for the
FieldServer to successfully respond.
 Common Data Transfer
Problems
‹ Data Types (Typecasting)
‹ Complex vs. Simple Data

Structures
‹ Bit Packing

‹ Supported functionality

in protocols
‹ Imperial vs. Metric
Common Data Transfer Problems
‹ Data Types (Typecasting)
• The FieldServer automatically typecasts data
unless special functions (like Packed Bit and
special moves) are used.
• Be careful therefore, not to put float values in an
integer data arrays for example, unless of course
you want to truncate at the decimal point.
‹ Complex vs. Simple Data Structures
• Protocols like LonWorks use complex data
structures to transfer multiple values in one data
address.
• Plan carefully when mapping complex data
structures to simple data structures. You will
need to make sure complex types are kept
together in the right arrays, and that the correct
number of data array
positions are allowed for, etc.
Common Data Transfer Problems
‹ Bit Packing
• Be aware that some devices send 16 status bits in an
integer to save address space and promote efficiency.
• Use Packed_Bit Data Arrays to provide binary status out
of a Packed_Bit integer.
‹ Supported functionality in protocols
• Expect “present value” data to be transferred between
different protocols at all times. However, auxiliary
properties (Like units, data quality, etc) is not always
supported by the “other” protocol.
• E.g.: Transferring BACnet data to Modbus will get you
the values you need, but the Units property will be lost
since Modbus does not support this.
‹ Imperial vs. Metric
• Foreign made devices often provide Metric values.
• Use Scaling in the FieldServer to do Metric->Imperial
conversions
 Resources
‹ FieldServer Website
(www.FieldServer.com)
• FieldServer Configuration Manual
• FieldServer Troubleshooting Manual
• Troubleshooting Application notes (ENotes)
 Questions?
Email Mac at:

sfint@comcast.net
 THANK YOU!

…..for taking the time to attend

this presentation.