![FieldServer FS-8700-74 Driver Manual Download Page 21](http://html.mh-extra.com/html/fieldserver/fs-8700-74/fs-8700-74_driver-manual_2287889021.webp)
FS-8700-74 Veeder Root Driver Manual
Page 21 of 33
FieldServer Technologies
1991 Tarob Court Milpitas, California 95035 USA
Web
:www.fieldserver.com
Tel
: (408) 262-2299
Fax
: (408) 262-9042
Toll_Free
: 888-509-1970
Appendix B. Trouble Shooting and Driver Error Messages
Driver statistics provide an effective troubleshooting method.
Generally RUINET may be used to monitor the driver stats. The connection overview screen
displays the number of messages & bytes sent / received as well as the number of errors.
As a point of departure:
•
The number of messages received should equal the number of messages sent.
•
The number of errors should be zero (in a perfect world) or should represent a small
percentage of the total number of messages sent (less then 5%).
•
Several errors in consecutive messages may cause the FieldServer kernel to place the node
offline in which case polling is slowed significantly until good communications are re-
established.
If the number of messages received is zero and the number of timeouts is equal to the number
of messages sent then
•
The connection is bad. Check the cables …
•
The security configuration is invalid
•
The port settings are incorrect. Check the baud rate ….
If the number of messages received and the number of messages sent are roughly equal and
the number of errors is small but the Data Arrays do not update then
•
If you are polling for System Status – Check the 1
st
element of the Data Array associated
with the poll Map Descriptor. The driver sets or clears the element as a summary alarm state
for the Veeder-root device. Check that the data age is no more than the scan interval.
If the number of messages ignored is non-zero then this indicates that some data cannot be
stored and is being discarded. Generally this arises when the driver cannot find an appropriate
Map Descriptor to store data received in response to a poll (for composite data such as system
status). For example: A system alarm occurs but you have not defined Map Descriptors to store
system alarms or an alarm occurs for a sensor for which you have not defined a Map
Descriptor.
You can monitor the error log to see if the driver has reported any errors or important
information. These messages arise in two ways. Firstly, there are configuration errors and
warnings which arise from the way that the CSV file has been configured. You should eliminate
all these errors before putting your system into production. Secondly there are errors that arise
from some run-time condition. Many of these errors are produced in the error log only once
even though they may be produced over and over. The driver suppresses repetition so that the
log does not overflow or hide other meaningful information.
Messages proceeded with an* are ones where multiple occurrences are suppressed by the
driver. Thus the error may occur continuously but only one occurrence will be reported in the
error log.