Technologies Computer Driver Instruction Manual

FS-8700-41 Simplex 4100 Driver Manual Page 26 of 58
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web:www.fieldserver.com
Tel: [phone] Fax: [phone] Toll_Free: 888-509-1970 email: [e-mail]
Appendix A.5. Simulation of the Xpoint command
The following notes apply only to FieldServer Technologies engineers.
The sim4100_func=xpoint keyword is used to parse unsolicited point status change
messages sent by Simplex devices. For simulation purposes it a wrbc version of this
function has been implemented to test the response parsing ability of the slave portion of the
driver.
Appendix A.6. Application Supervision Messages
Section 7.2 of the Simplex 4100 protocol describes unsolicited messages from a Simplex
device. This sim4100_func=super wrbc command is used to test the driver's ability to parse
these messages.
The 4100 protocol supports a periodic application supervision message. This supervision
poll is performed if the TERMINAL flag POLL is set (COMPUTER DEFAULT). The objective
of the supervision poll is two-fold:
• It is the only periodic message that can be expected to be sent by the 4100, thus
establishing the basis for supervising the line.
• To ensure that all layers of the two systems are operating properly and able to respond
to messages. For example, in a PC implementation that uses a Terminate-and-Stay-
Resident (TSR) device driver to implement the protocol, the answer to the supervision
poll should be done in a way such that if the program exits to DOS, the TSR will not
continue to indicate to the 4100 that everything is OK, when in fact, the PC will not be
able to annunciate an alarm.
Appendix A.7. Driver Stats
Appendix A.7.1. How the Driver counts bytes and messages
received and transmitted.
"Ack" messages sent/received by the driver in response to read/write messages are
NOT counted as messages. However, the single byte produced by these messages is
included in the byte count.
The driver does not count DLL layer messages as messages.
The driver counts bytes at the DLL layer. The byte count includes the bytes that wrap
application layer messages, acks and the port supervision and responses messages.
The driver counts messages at the application layer.. This means that if you use
RUINET to monitor the FieldServer and you view the Map Descriptor’s the byte count
stats will always be zero.
Some Map Descriptors require data in the Data Arrays to trigger a write command. An
example is the "Ack" command. The driver does not count one of these messages as
being sent until the array actually triggers a poll to be sent.