Frage deutsch
~~~~~~~~~~~~~~
Wie konfiguriere ich den COM Port?
Question English
~~~~~~~~~~~~~~~
How should I set up my COMmunications line in QuickBasic 4.50?
Answer 1
~~~~~~~~~~
[ from the QB-FAQ 1 of the Microsoft Knowledge Base at http://www.microsoft.com ]
.
If you have problems using COM1 or COM2, try the following OPEN statement,
which makes Basic as tolerant as possible of hardware- related problems:
OPEN "COM1:300,N,8,1,BIN,CD0,CS0,DS0,OP0,RS,TB2048,RB2048" AS #1
(This OPEN is FOR RANDOM access.) The following is an explanation of each
recommended parameter used in this OPEN statement:
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, required to turn on parity checking) in the OPEN COM statement. 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:
OPEN "COM1:1200,O,7,2,PE" FOR RANDOM AS #1
and
OPEN "COM2:1200,E,7,2,PE" FOR RANDOM AS #2
If the PE option is removed from the OPEN COM statements above, no error
message displays.
8 data bits require 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 bytes.
RB2048 = Increases the receive buffer size to 2048 bytes.
A larger receive buffer can help you work around Basic delays caused by
statements such as PAINT, which use the processor intensively.
The following are additional important hints for troubleshooting
communications problems:
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).
For an example of data communications, please refer to the TERMINAL.BAS
sample program that comes on the release disk for QuickBasic version 4.50. Many
communications problems may actually be due to inappropriate source code design
and flow of control.
Many communications problems can be shown only 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 cause 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 help you 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.
Many commercial communications programs use sophisticated techniques not
found in Microsoft Basic, and may give better performance.
If you need better communications performance than you are getting from
Basic, you may want to try Microsoft C. (You can call Microsoft C versions 5.x
routines from QuickBasic version 4.50.)
Answer 2
~~~~~~~~~~~~~~~~
[ from the QuickBASIC 7.1 online help ]
*** Problem
I'm having problems opening a communications port. What is a good
general OPEN statement that I can test it with?
*** Solution
The following OPEN statement is very general and will be accepted by most
configurations:
OPEN "COM1: 300,N,8,1,BIN,CD0,CS0,DS0,OP0,RS,TB2048,RB2048" AS
#1
For specific information on syntax, see the QB online help under OPEN COM
[ The QBasic-MonsterFAQ --- Start Page: www.antonis.de/faq ]