This article gives a sample OPEN COM statement that should work correctly. Additional communications troubleshooting hints are also given. For a related article, see the following article in the Microsoft Knowledge Base:
- The higher the baud rate, the greater the chances for problems; thus, 300 baud is unlikely to give you problems. 2400 baud is the highest speed possible over most telephone lines, due to their limited high-frequency capability. 19,200 baud, which requires a direct wire connection, is most likely to cause problems. (Possible baud rates for QuickBasic are 75, 110, 150, 300, 600, 1200, 1800, 2400, 4800, 9600, and 19,200.)
- Parity usually does not help you significantly; because of this, you should try No parity (N).
For those devices that require parity, you should use the PE option (Parity Enable) in the OPEN COM statement, which is required to turn on parity checking. When the PE option turns on parity checking, a "Device I/O error" occurs if the two communicating programs have two different parities. (Parity can be Even, Odd, None, Space, or Mark). For example, a "Device I/O error" occurs when two programs try to talk to each other across a serial line using the following two different OPEN COM statements:and
OPEN "COM1:1200,O,7,2,PE" FOR RANDOM AS #1If the PE option is removed from the OPEN COM statements above, no error message displays.
OPEN "COM2:1200,E,7,2,PE" FOR RANDOM AS #2
- The above example uses 8 data bits and 1 stop bit. Eight data bits requires No parity (N), because of the size limit for Basic's communications data frame (10 bits).
- The BIN (binary mode) is the default. Note: The ASC option does NOT support XON/XOFF protocol, and the XON and XOFF characters are passed without special handling.
- Ignoring hardware handshaking often corrects many problems. Thus, if your application does not require handshaking, you should try turning off the following hardware line-checking:CD0 = Turns off time-out for Data Carrier Detect (DCD) line
CS0 = Turns off time-out for Clear To Send (CTS) line
DS0 = Turns off time-out for Data Set Ready (DSR) line
OP0 = Turns off time-out for a successful OPEN
- RS suppresses detection of Request To Send (RTS).
- For buffer-related problems, try increasing the transmit and receive buffer sizes above the 512-byte default:TB2048 = Increases the transmit buffer size to 2048 bytesA larger receive buffer can help you work around Basic delays caused by statements like PAINT, which use the processor intensively.
RB2048 = Increases the receive buffer size to 2048 bytes
- You should use the INPUT$(x) function in conjunction with the LOC(n) function to receive all input from the communications device (where "x" is the number of characters returned by LOC(n), which is the number of characters in the input queue waiting to be read. "n" is the file number that you OPENed for "COM1:" or "COM2:").
Avoid using the INPUT#n statement to input from the communications port because INPUT#n waits for a carriage return (ASCII 13) character.
Avoid using the GET#n statement for communications because GET#n waits for the buffer to fill (and buffer overrun could then occur).
Also, avoid using the PUT#n statement for communications, and use the PRINT#n statement instead. For example, in QuickBasic 4.0b and 4.5, in Basic Compiler 6.0 and 6.0b, and in Basic PDS 7.0 and 7.1, using the PUT#n,,x$ syntax for sending a variable-length string variable as the third argument of the PUT#n statement sends an extra 2 bytes containing the string length before the actual string. These 2 length bytes sent to the communications port may confuse your receiving program if it is not designed to handle them. No length bytes are sent with PUT#n,,x$ in QuickBasic 4.0. (QuickBasic versions earlier than 4.0 don't offer the feature to use a variable as the third argument of the PUT#n statement.)
- For an example of data communications, please refer to the TERMINAL.BAS sample program that comes on the release disk for QuickBasic versions 4.0, 4.0b, and 4.5, for Microsoft Basic Compiler versions 6.0 and 6.0b, and for Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1. Many communications problems may actually be due to inappropriate source code design and flow of control.
- Many communications problems can only be shown on certain hardware configurations and are difficult to resolve or duplicate on other computers. We recommend experimenting with a direct connection (with a short null-modem cable) instead of with a phone/modem link between sender and receiver to isolate problems on a given configuration.
- The wiring schemes for cables vary widely. Check the pin wiring on your cable. For direct cable connections, a long or high-resistance cable is more likely to give problems than a short, low-resistance cable.
- If both "COM1:" and "COM2:" are open, "COM2:" will be serviced first. At high baud rates, "COM1:" can lose characters when competing for processor time with "COM2:".
- Using the ON COM GOSUB statement instead of polling the LOC(n) function to detect communications input can sometimes work around timing or buffering problems caused by delays in Basic. Delays in Basic can be caused by string-space garbage collection, PAINT statements, or other operations that heavily use the processor.
- Make certain that the appropriate hardware handshaking lines (i.e. CS, DS, CD, etc) are being checked by Basic. Although disabling these timeouts (setting the corresponding value in the Basic OPEN statement to zero) is useful for determining what lines your hardware uses, it should not be considered a general purpose method for establishing serial communications, since ignoring hardware handshaking may increase the possibility of a timing problem that could lead to a hang.
If you need better communications performance than you are getting through Basic, you may want to try Microsoft C. (You can call Microsoft C routines from Microsoft QuickBasic 4.0, 4.0b, and 4.5, from Microsoft Basic Compiler 6.0 and 6.0b, and from Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1.) The following is an excellent reference:
The following book gives an excellent technical, hardware-level description of serial communications for the IBM PC:
Article ID: 39342 - Last Review: 16 Aug 2005 - Revision: 1