User Guide

FS-8700-86 Carrier DataPort Page 29 of 32
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Tel: [phone] Fax: [phone] Toll Free: [phone] email: [e-mail]
Error Message Explanation
works best with long
timeouts.
each table is different. The driver does not know the length of the
responses. The Carrier devices take some time between receiving a poll
and sending a response. The amount of time is proportional to the length
of the response (and hence, to the size of the table.) If the device takes
too long the driver may timeout as the default timeout is 2.0 seconds. It is
strongly recommended that you set the timeout to a large value (like 30
seconds) to start with. The effect of having a large timeout is to
1) allow the driver enough time to receive the response and
2) Increase the amount of time before the driver reports the timeout if
there is a genuine timeout event.
CarrDP:#26 FYI. No data
was stored for MD=%s
This message is printed when a response is received but the driver did
not find any information in the response that it could use to store. If the
problem occurs repeatedly then take a log and call tech Support after you
have tried the following diagnostic steps. 1) Check connection stats – If
bytes received per message is < 100 then it is likely that the device you
are polling is not responding properly or that a port setting is invalid.
Check the port settings.
CarrDP:#27 Err. Can’t open
slave.log
This message should only be printed in simulation mode (QA testing). If
you see this message call Tech Support.
CarrDP:#28 FYI. Response
was sent from slave.log
(Hex file)
This message should only be printed in simulation mode (QA testing). If
you see this message call Tech Support.
CarrDP:#29 Err. The input
buffer has overflowed.
This message could be produced when the characters which signal the
end of a response are missing and the next response is appended to the
1
st
in the input buffer. In such cases the buffer may overflow.
This message is printed once and then suppressed. However each time
the event occurs, the STREAMING stat is incremented by one.
If the stat is produced rarely then you could assume that that an
occasional corrupt/incomplete message has produced the error.
If it occurs all the time, then assume that the response is too large to fit in
the input buffer.
Most FST drivers have an input buffer of 3080 bytes This driver has a
buffer size of 16000 bytes. The buffer size is hard coded so you will need
to capture a log and send an error report to FST.
CarrDP: #30
CarrDP:#31 Err. Line has
missing CR. Some data not
stored
CarrDP:#32 Err. Many
missing CR's. Abandon
store... MD=%s
When parsing a response, the driver processes the response line by line.
A single response may consist of a number of lines. Each line is
terminated with a Carriage Return (CR). If a single CR is missing then
the driver sees two lines as a single line. In versions prior to 1.03eA the
driver used the line number as the offset, therefore values extracted from
subsequent lines were stored at the incorrect offset. Now the driver
ignores the corrupted line and advances the line counter by 2 continuing
the parsing and storing of extracted values. The values associated with
the corrupted response line are not updated. This is reflected in the line
count stored at offset zero. The driver detects lines with missing CR's by
checking the line length. If the driver senses that more than two or more
consecutive CR's are missing then the driver abandons the parse and
store and prints error #32. If different parts of the response have missing
CR's message #31 will be printed more than once per response. There
is no direct corrective action you can take. The errors arise from dropped
bytes in the response. If the error occurs frequently you will need to
check that the data transmission is not being adversely affected by noise.