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',