comm info |
This table contains the following information:
Field Number |
Field Name |
DE Type |
Possible Values |
0 |
key up delay |
rtINT16 |
-32,767 to +32,767 (msec) |
1 |
key down delay |
rtINT16 |
0 to 32,767 (msec) |
2 |
channel clear delay |
rtUINT16 |
0 to 65,535 (msec) |
3 |
turn around delay |
rtUINT16 |
0 to 65,535 (msec) |
Where:
Field Name |
Description |
key up delay |
The desired time to wait (in milliseconds) after
asserting RTS (request to send), before sending data. If the value
is 0 (zero), no RTS is asserted. If the value is greater than zero,
the host will wait that number of milliseconds, after asserting RTS,
before beginning transmission, regardless of the value of CTS (clear
to send). If the value is less than zero, the host will wait until
either the CTS signal is received, or the specified number of
milliseconds has expired before transmitting. If the specified time
expires before CTS is received, the transmission fails. |
key down delay |
The desired time to wait (in milliseconds) after the
last data character has been sent, before resetting RTS (request to
send). This should be a positive number; if the value is negative,
the minimum time of rtNap() is used (see Section 3 of the RTAP
Reference Manual for details). |
channel clear delay |
The desired time to wait (in milliseconds) for the DCD
(data carrier detect) line to clear before asserting RTS. If this
value is zero, the DCD line will be ignored. If the value is
positive, the host will wait the specified number of milliseconds
for the DCD to clear before asserting RTS. If the DCD line has not
cleared before the specified time has expired, the transmission
fails. |
turn around delay |
The desired time to wait (in milliseconds) after data
has been transmitted in either direction, before a transmission in
the opposite direction is initiated. This time must be at least the
sum of the "channel clear delay", "key up delay" and "key down
delay". |
|
rs232 info |
This table contains the following
information:
Field Number |
Field Name |
DE Type |
Possible Values |
0 |
baud rate |
rtUINT16 |
50 to 19200 (bits/sec.) |
1 |
data bits |
rtUINT8 |
7 or 8 (bits) |
2 |
stop bits |
rtUINT8 |
1 or 2 (bits) |
3 |
parity |
rtUINT8 |
0=none, 1=odd, 2=even |
4 |
reserved |
rtUINT8 |
|
Where:
Field Name |
Description |
baud rate |
The transmission rate of the communication
line in bits per second. |
data bits |
The number of significant bits within a
transmitted character or byte. |
stop bits |
The number of bits indicating the end of a
transmitted character. |
parity |
The type of parity used for verifying
correct communication at the character level. Parity can be either
even, odd, or none. If parity is specified, and a parity error
occurs, then the character is ignored. This will cause a
communication error. |
|
debug level |
A debug level used to determine the amount
of communication port information printed to the debug
device. Higher debug levels print more detailed information. A
debug level of zero indicates that no debug information is to be
printed to the debug device. |
debug device |
UNIX |
The device file where debug information is
to be printed. The full path must be provided; for example "/dev/ptyqf ".
In addition to a device file, the following key words are
recognized: "stdout " and "stderr "; which
send debug information to the specified file pointer.
|
If a pseudo-terminal device is to be used, specify the
master device; otherwise the driver will be hung on the open
waiting for the master side of the pseudo-terminal to be opened. |
|
If a pseudo-terminal device is used, the scan task must
be started before any process tries to open the slave
device; otherwise no debug information will be printed. |
|
Windows |
This specifies a "named pipe" that will
be created on the server machine. Client applications can then make
connections to this "named pipe" to receive debug information. A
separate thread is created to handle each client. There is a maximum
of six client connections allowed. Additional clients trying to
connect will fail.
Since this is a "named pipe", clients can connect
from other machines on the network.
See the tesserNet Scan Debug Utilities for freely distributable
client applications.
|
Depending on the network connection speed, some debug
data may be lost. Tests here, show that for a full 10 Mbit/sec
connection, no data is lost. |
|