...
Communication line parameters of "Serial", "Serial Line Redundant", and "Serial System&Line Redundant" categories do not depend on the hardware used for serial communication, because the operation of serial interfaces is solved by means of asynchronous port drivers in Windows system (device drivers) or Linux serial port interface. Definitions are the same either for communication via standard ports COM1 up to COM4COM99, or e.g. via intelligent asynchronous communication adapters DigiBoard, Moxa, VSCOM, or other extension cards or devices. These parameters may be configured in four independent modes. Communication stations can subsequently use one (or even more) of these modes for their communication.
Note: if the D2000 KOM process is running on a Linux/Raspberry PI platform, you must enter the Device parameter value as a full path to the device that corresponds to the serial port (eg /dev/ttyAMA0 or /dev/ttyS0).
Parameters
Baud rate
Setting of the line baud rate. Valid values: 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400.
Number of bits
A number of data bits. Valid values: 5, 6, 7, 8.
Number of stop bits
A number of stop bits. Valid values: 1, 1.5, 2.
Illegal combinations:
5 data bits and 2 stop bits,
6, 7, or 8 data bits and 1.5 stop bit.
...
DTR/DSR
Custom mode sets DTR as the active signal for the handshaking control.
RTS/CTS
Custom mode sets RTS as the active signal for the handshaking control.
Inverse
For the handshaking of Custom type, controlled signals RTS or DTR are inverted.
RTS=0 (RTS=1)
It sets a constant RTS signal level in case that is not actively used by the selected handshaking type.
DTR=0 (DTR=1)
It sets a constant DTR signal level in case that is not actively used by the selected handshaking type.
WaitTxEMPTY
If the option is enabled, the communication thread is waiting for the transmission to end. The option enables the synchronization of RTS or DTR signal control at the end of the transmission (see Receive delay) in case of the handshake of Custom type. As the standard serial drivers of Windows operating systems allow to get information only about the transmission of the last byte into the transmission shift register of the UART device (but not physically sent out), then in the case of this option, there is 1 character with 0xFF value added to the end of the transmitted message. At the moment of transmission indication of this character into the transmit register, the inherent message is sent out safely, and Receive delay (if nonzero) is starting to tick. See also Note.
Transmit delay
Delay (in milliseconds), that is inserted between the RTS signal setting (Custom handshaking RTS/CTS) or DTR signal setting (Custom handshaking DTR/DSR) and the beginning of message transmission.
Receive delay
Delay (in milliseconds), that is inserted from the end of the transmission to the deactivation of the RTS signal (Custom handshaking RTS/CTS) or DTR signal (Custom handshaking DTR/DSR). For the real starting of this delay at the moment of the transmission end, it is necessary to use the WaitTxEMPTY option.
...