| transmission mode |
Specifies the communication mode as either ASCII
(zero) or RTU (one). |
| 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. |
|
| max data length |
The request(s) will be formatted such that
the number of data bytes returned from the RTU will not exceed this
number. This value is only read on startup. The minimum
value for this is four. If the value is less than this minimum, it
will be silently set to the minimum. |
| process number |
If this attribute is present, the RTAP
process number of the scan task for this communication port will be
written here. |
| socket |
Specifies whether the scan task should use
a socket connection. |
| socket info |
Specifies the host and service name to use
when making a socket connection. This attribute is only used if
"socket" is set to one. The entry to use is specified in the "socket
index" attribute. This table contains the following:
| Field Number |
Field Name |
DE Type |
Possible Values |
| 0 |
host name |
rtBYTES16 |
(see below) |
| 1 |
service name |
rtBYTES12 |
(see below) |
Where:
| Field Name |
Description |
| host name |
Valid host name in either IP format (e.g. 1.2.3.4) or
hostname from /etc/hosts. |
| service name |
Valid service name from /etc/services.
The socket num ber specified should be specified using tcp (eg. modbus_sock
19000/tcp ). |
|
| socket index |
Specifies the index into the "socket info"
table of the entry to use. Only used if "socket" is set to one. |
| 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.
![[warning]](../Images/warnicon.png) |
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. |
![[caution]](../Images/cauticon.png) |
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. |
|