Download 1.0 INTRODUCTION LINX II, III, and IV terminals can be attached to

625 Digital Drive, Plano, TX 75075 Tel: (972) 964-7090 Fax: (972) 964-7643 Web Page: www.linxdata.com
LINX POLLED MODE PROTOCOL
• Revision Date: January 11, 2000
Article 15
1.0
INTRODUCTION
LINX II, III, and IV terminals can be attached to any host computer that has an RS-232 or RS-4221
serial ASCII communications port. This includes IBM mainframes with protocol converters, DEC
PDP-11 and VAX, UNISYS, HP-9000, and other minis, and PC compatibles running UNIX,
XENIX, OS/2, and Apple Macintosh systems.
You can write your polling program in QuickBASIC, VisualBasic, C, or other languages that
support COM port communications. (Note: Microsoft BASICs do not support COM3 or higher.)
These terminals are designed to use one of 3 different communications protocols: XON/XOFF,
POLLED MODE, and REQUEST/RESPONSE. Of these, REQUEST/RESPONSE is the most
secure, but is also the most difficult to implement, being a true datacomm protocol. It is the subject
of another document (the LINX Request/Response Protocol Manual), and is mandatory reading if
you choose to implement it. It is highly recommended when communicating over any modem link
or any other link where noise is the rule rather than the exception. The POLLED MODE protocol is
unsuitable for noisy communications lines, since it does not perform error checking of data.
POLLED MODE is the most commonly used protocol. Supported by both LIO, TopSail's L4IO
driver, and LinxASCIIPlus, it is the most popular protocol for its relative ease of implementation
and freedom from errors. However, there are some specific rules that, if not followed, will cause
the implementer a great deal of stress!
1.1
EXPERIENCING LINX COMMUNICATIONS
The first step in designing the LINX-to-Host interface program is to understand how LINX
terminals communicate. No amount of technical descriptions can replace the knowledge gained
from a short session with a terminal emulation program running on the host. We use
HyperTerminal for our testing at LINX.
Another useful device is a Data Line Monitor, which, placed between the LINX and the host
computer, will display all data records going to and from each device.
Put the terminal into POLLED MODE, hook up your PC, and start pressing ENTER (or
CARRIAGE RETURN), and watch what happens. This will help you more than any technical
treatise.
1
to.
The Master/Gateway terminal must be ordered with the same type port (RS232 or RS422) as the host it is connected
1.2
GENERAL GUIDELINES
The host program must be able to perform the following functions:
a)
b)
c)
d)
Get the status of terminals on the network
Collect data from the network
Send commands to individual or all terminals
Download files to the a terminal or all terminals
It is important that you plan to record all status information you receive from the network (in an
array, for instance), so that you will know whether a given terminal is online before you try to send
something to it.
1.3
POLLED MODE PROTOCOL DETAILS
In POLLED MODE, the LINX master only speaks when spoken to. The host sends a Carriage
Return <CR> to the LINX to request data.
Every <CR> received by the LINX master terminal WILL generate one of the following 3 replies:
1. A data record from any terminal in the network;
OR
2. A status record from any terminal in the network;
OR
3. An asterisk (*) if nothing else to reply
No error checking other than character parity is performed, so this protocol is suited for directconnect environments where checksums are not required. (LinxBASIC programs contain their own
checksums that are tested by the interpreter. Therefore, you can assume that no invalid programs
will be accepted or run by the LINX, and any errors which occur during downloading of programs
will cause an error message to be sent back to the host.)
A record will be re-transmitted if the Host sends a <NAK> (hex 21 or Control/U) to the Master
terminal.
SPECIAL NOTES:
a. Any record you send to a terminal also constitutes a valid POLL for data, so your program
should perform a READ for data after you send any record to the terminal.
b. Always poll any available data from a LINX before transmitting any new line of program
or data. The host should always send a Carriage Return to the LINX before each line of command
or download file, and should retrieve ALL data records waiting (keep polling until you receive an
asterisk) before sending the next line!
c. ECHO must be disabled on the Master terminal! If ECHO is enabled (via the Comm Port
Menu), then each record sent by the Host will first be echoed back to the host, and will then be
followed by the data record. This will cause an out of sync condition to occur which will eventually
crash the LINX! So, make sure you have ECHO disabled on the Master. You will occasionally see
references in this document to POLLED mode using a Question Mark ("?") followed by Carriage
Return for its polling sequence. This is permissible, and can be useful in determining if the LINX
has its ECHO enabled, because the response will be a question mark from the master, which is of
course, an invalid response!
d. If you receive a garbled record, send a <NAK> (hex 21 or Control/U) instead of a <CR>, and
the LINX Master will re-transmit the record. You can do this as many times as it takes to receive a
good record. Test your 10 byte prefix (see the LINX User's Guide) for validity. In particular, check
to see that the sequence number starts at 01 and runs to 99 and starts over again to make sure you
haven't lost any records.
e. Just because you receive an asterisk does not mean all the terminals are empty. It is possible
to have data queued up in terminals, and still get a series of several asterisks due to network polling
speeds and other conditions. We suggest you keep polling until you get several seconds' worth of
asterisks (or around 40 *’s) before assuming the terminals are all empty.
1.4
SAMPLE SUBROUTINES
The following are some sample subroutines required to implement POLLED MODE protocol.
These were taken from an early version of LIO (V3.0), but you can examine the newer LIO or L4IO
(Topsail driver) source code to see other code examples.
SUBROUTINE SendRecord: Send a Record to a terminal
- Call Poll til asterisk received (Master ready to receive)
- Make sure terminal is online (see Poll subroutine)
- Append Terminal Number to front of record
- Send record out the comm port
SUBROUTINE LinxIn: Input a record
- Set timeout value
- Set error threshold
- LOOP, Attempting to get a character or line of data
- If timeout, terminate
- If errors exceed threshold, terminate
- Append character to buffer
- CRLF signals proper end of record
- Return error or non-error status, and buffer contents
SUBROUTINE Poll: Poll for a record
- Send a "?"<CR> out comm port (only if you have not just
finished sending a data record with <CR> to the LINX)
- Call LinxIn to get a record
- IF the input record = "*" (Meaning LINX has no data)
- Yes: Return with no data
- IF the input record = "?" (Meaning LINX is echoing data)
- Yes: Error, disable ECHO in COMM PORT MENU
- IF the input record length < 10?
- Yes: Error, Invalid rec. Should have 10-byte prefix
Send a <NAK> and loop back to call LinxIn
- IF sequence number (5th and 6th bytes) are out of order
- Yes: Error, Send a <NAK> as above
- Timed out with no record input?
- Yes: Error, LINX not responding
- Are the 11th and 12th bytes of the prefix one of these:
- ON: Terminal is Online
- OF: Terminal is Offline
- MO: Terminal is a Master
- BA: BASIC program error. Text in rest of record.
- ER: BARCON program error. Text in rest of record.
- SO: Terminal is a Sub-Master
- CO: Terminal is a Concentrator
- DU: Duplicate masters with same Terminal Number
- ND: Program loader failure or network directive reply
- Store data record in file
SUBROUTINE Download a File to a terminal
- Make sure file to be downloaded exists
- Make sure terminal is online
- LOOP through records in the download file
- Call SendRecord to output each record
- Terminate
1.5
OPTIONAL FUNCTIONS
The following functions may or may not be required, depending on your application:
Get full terminal status information
- Call SendRecord to send a <S directive;
- Get reply (Serial Number)
- Call SendRecord to send a <V directive;
- Get reply (Firmware Version)
- Call SendRecord to send a <D directive;
- Get reply (What's on the Display)
- Call SendRecord to send a <E directive;
- Get reply (Last Error)
- Call SendRecord to send a <T directive;
- Get reply (Time and Date)
Abort Currently Running BASIC Program
- Call SendRecord to send a >>A directive
Restart an aborted BASIC Program
- Call SendRecord to send a >>G directive
Send any Network Directive
- Get command desired from operator
- Call SendRecord to send the command
- Display all reply records
Set Date and Time on all terminals
- LOOP through all terminals on network
- Call SendRecord to send a >T directive
with hhmmss00mmddyyyy
Other functions
See the LINX User's Guide chapter on Network Directives for any other commands which might be
beneficial to your environment.
1.6
HOST LOOKUPS
If you are implementing host file lookups, they should be implemented with a request stack as
shown in the following sequence. This will ensure that no reply is ever sent from the host without it
having first received an asterisk (*) indicating a clear network status:
Host sends a <CR> poll
Master sends Request #1 to the host
Host receives request and pushes it onto a queue
Host sends a <CR> poll
Master sends Request #2 to the host
Host receives request and pushes it onto the queue
Host sends a <CR> poll
Master sends an asterisk (*) indicating no further data
Host pops Request #1 off stack and does lookup
Host sends reply to #1, terminated with <CR>
Master sends reply to destination terminal
Since reply ended with <CR>, Master sends Request #3
Host receives request and pushes it onto the queue
Host sends a <CR> poll
Master sends an asterisk (*) indicating no further data
Host pops Request #2 off stack and does lookup
Host sends reply to #2, terminated with <CR>
Master sends reply to destination terminal
Master has no more data, and sends asterisk (*)
Host pops Request #3 off stack and does lookup
Host sends reply to #3, terminated with <CR>
Master sends reply to destination terminal
etc.