Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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.