Instruction manual
APPENDIX A. TROUBLESHOOTING
A-2
A.2 COMMUNICATION PROBLEMS
The approach taken here is to isolate where
communication is having difficulty and then
attempt to remedy the problem. There is a
section for each type of communication link.
Keep in mind that DlsMgr will attempt to
communicate with a datalogger when it has a
reason to do so. The most common reason is
to poll the datalogger for data. Other reasons
include checking the clock, terminal mode, etc.
When these operations fail due to
communication problems, they will be retried
based on the retry values entered in the net
description. Messages relating to
communication are only generated when these
operations are taking place. Some operations
(like the clock set) have a button to force an
immediate retry (KICK button). The Terminal
mode also will force a communication attempt.
If RTMS or the OS/2 computer is suspect, DOS
based GraphTerm (GT) Version 2.2 or newer
can be used to verify the communication
hardware and datalogger.
It is important to try some of these troubleshooting
techniques while a network is functional. It can be
very difficult to recognize abnormal behavior when
not familiar with normal operations.
Messages from the NetAdmin SWF$.LOG are
used in the following sections. The format of
these messages is TIMESTAMP,TYPE,FROM,
ABOUT,MESSAGE.
• TIMESTAMP indicates when the message
occurred
• TYPE indicates type of message: STATUS,
WARNING, or FAULT
• FROM indicates which station originated the
message.
• ABOUT indicates which station the
message is about.
• MESSAGE is the text of the message. The
messages shown here came from several
example networks.
PC1 is the computer, CR10T is a datalogger
directly connected to COM1. Stn2 is a
datalogger site accessed via telephone modem
on COM1. MD91 is accessed via MD9.
RF2BASE is a RF232T base station and RF1 is
a radio remote datalogger station. The
RF2BASE is connected to COM1.
A2.1 DIRECT CONNECTION (SC32A OR RAD
MODEMS)
With direct connection there are several things
to check. Section 1.2 will verify that data is not
being updated. Attempt a clock check or try the
terminal mode. If they succeed then it is
probably not a communication problem but a
data selection or computer problem (see
Section 3).
Check the PORT ACTIVITY box on the
NetAdmin main screen. Select the COM port
used to communicate with the station. Select
the RESET COUNTERS buttons. Examine the
CHARS TX, and CHARS RX, and RETRIES
boxes. The TX box indicated how many
characters are sent to the datalogger and the
RX indicates how many characters are
received. The TX box will be non-zero when
communication is attempted. The RX will be
non-zero when the datalogger responds. The
most common case is when the datalogger fails
to respond. In this case the TX box will be
growing larger while the RX box remains at
zero. The SWF$.LOG will have warnings and
faults like the following:
'08-18-94 15:01:17','W','PC1','CR10T',
'SerLine timeout retry on: COM1.'
'08-18-94 15:01:18','W','PC1','CR10T',
'SerLine timeout retry on: COM1.'
'08-18-94 15:01:18','W','PC1','CR10T',
'SerLine timeout retry on: COM1.'
'08-18-94 15:01:19','W','PC1','CR10T',
'SerLine timeout retry on: COM1.'
'08-18-94 15:01:20','F','PC1','CR10T',
'SerLine timeout retry on: COM1.'
'08-18-94 15:01:28','F','PC1','CR10T','Link
failed.'
This pattern will repeat with several warnings
preceding each fault.
Things to check:
• Ensure that the correct COM port is
selected in the Net Description.
• Ensure that each cable is connected
properly.
• The cable connecting the computer and the
SC32A should not be a “Null Modem” cable,
but should be a standard serial RS232