Serial (COM) port
COM port is short for a serial communication port. Most serial communication software communicate with a computer through a communication port, and most IBM and IBM-compatible computers support up to four serial ports COM1, COM2, COM3 and COM4. Additional ports can be added by adding additional hardware.
Serial Printer Logger can manipulate with many serial ports in the same time (up to 255 serial ports).
You can open serial ports in Serial Printer Logger software in two modes:
If one or more port are configured already, then Serial Printer Logger is opening these ports and starting logging. If the port is opened successful, then the status bar in the main window displays a status of this port (fig. 1.1.1). But, before you should configure serial port parameters. For minimization of configuration we combined serial ports with same settings to the "Configuration". The configuration can include one or more serial ports with identical settings. For example, if you have many identical devices, that connected to different serial ports, then you can specify port numbers in one configuration only. But, if you want to use serial port with different settings, then you should create more than one configurations.
You can create the new configuration by clicking the "Plus" button in the main window (fig. 1.1.1) or through the "Options" menu. After you clicked the "Plus" button, the dialog window will be opened (fig. 2.1.2). The dialog window contains few sections with parameters. The "COM port" section is described in this chapter.
You can manage the configuration created with a drop down menu near the "Plus" button (fig. 2.1.1).
Fig. 2.1.1 Access to the port configuration
The "COM port settings" tab contains indispensable settings of any serial port: baud rate, data bits, etc. You should configure it with same values, that your external device uses for data exchange.
Fig. 2.1.2 COM port parameters
If you are logging data over RS-485 with an additional hardware converter and your converter doesn't support data direction auto detection, then specify "RS485 interface mode". This option instructs Serial Printer Logger to set the RTS line at low level while data receiving and vice versa. The serial port driver can detect errors while data receiving (for example, bad quality of a connection line). You can specify with the "At data receive error clean incoming buffer" option to ignore data blocks, that contain errors and clean an incoming buffer.
In some cases the program can't open a serial port while starting (for example, the port is already used by other application). With the "Try to open after an unsuccessful attempt" option you can specify to try to open the serial port again after the interval specified. The program will try to open the serial port until an attempt will successful.
The Windows communication API provides two methods to check for received data and line/modem status changes: API calls (polling) and an event word. The event word is maintained by the Windows communications driver. As data is received or line/modem status changes occur, the driver sets bits in the event word. The application can check the bits to determine if any communication events occurred. If so, the application can make the appropriate API call to clear the event word and retrieve the data or the new line/modem status values.
Windows also provides API calls to retrieve the same status information provided by the event word but the API calls are slower. Serial Printer Logger uses the event word by default for the fastest possible performance. Unfortunately, there is at least one communication driver (WRPI.DRV, included with some U.S. Robotics modems) that doesn't appear to support the event word. For this and similar drivers, select other mode before Serial Printer Logger will receive data.
To rise data transmit adequacy you can use hardware and/or software data flow control (fig. 2.1.3). When using hardware data flow control are used some lines (wires) of connecting cable. Depending on used lines, you must setup checks against corresponding fields.
Hardware flow control
When the hardware flow control options are an empty, as they are by default, there is no hardware flow control. The options can be combined to enable hardware flow control.
"Receive flow control" stops a remote device from transmitting while the local input buffer is too full. "Transmit flow control" stops the local device from transmitting while the remote input buffer is too full.
Receive flow control is enabled by including the "Use RTS" and/or "Use DTR" elements in the options. When enabled, the corresponding modem control signals (RTS and/or DTR) are lowered when the input buffer reaches the 90% size of the buffer. The remote must recognize these signals and stop sending data while they are held low.
As the application processes received characters, buffer usage eventually drops below the 10% size of the buffer. At that point, the corresponding modem control signals are raised again. The remote must recognize these signals and start sending data again.
Transmit flow control is enabled by including the "Require CTS" and/or "Require DSR" elements in the options. With one or both of these options enabled, the Windows communications driver doesn't transmit data unless the remote device is providing the corresponding modem status signal (CTS and/or DSR). The remote must raise and lower these signals when needed to control the flow of transmitted characters.
Note that flow control using RTS and CTS is much more common than flow control using DTR and DSR.
Software flow control
This routine turns on one or both aspects of automatic software flow control based on the value assigned to the property.
"Receive flow control" stops a remote device from transmitting while the local receive buffer is too full. "Transmit flow control" stops the local device from transmitting while the remote receive buffer is too full.
Receive flow control is enabled by assigning "On receiving" or "Both" to the "Type" property. When enabled, an XOff character is sent when the input buffer reaches the level 10% size of the buffer. The remote must recognize this character and stop sending data after it is received.
As the application processes received characters, buffer usage eventually drops below the level 10% of the buffer. At that point, an XOn character is sent. The remote must recognize this character and start sending data again.
Transmit flow control is enabled by assigning "On transmitting" or "Both" to the "Type" property. The 10% and 90% size of the buffer are not used in this case. When transmit flow control is enabled, the communications driver stops transmitting whenever it receives an XOff character. The driver does not start transmitting again until it receives an XOn character or the user sets software flow control to "None'.
Software data flow control can be setup on receive, transmit or both modes, but so as the great number of device doesn't need data sending, select only control mode "On receive". In case of activation of data transmit control remote object (in our case your device) can send special codes, signalizing about data transmit stop or start. On default, received from device character 0x11 Hex signalizes to COM port driver to start data receive and character 0x13 Hex - to stop data receive from device.
Fig. 2.1.3 Data flow control
In this mode Serial Printer Logger doesn't send and receive any data, and only spies data exchange, made by other programs.
To spy received and sent data open COM port before running the given program. If the given program receives data over COM port, the data exchange process will be displayed in data receive window. Don't forget to set up check box "Spy mode" to spy data receive by the given program (if necessary).
To exit Serial Printer Logger close the given program or stop data exchange over COM port in it.
you must close, which data exchange you spies, before closing Serial Printer Logger.
Line errors can occur during data exchange and displayed in the main program window in the status bar.
UART receiver parity error - occurs if you configured invalid parity type;
UART receiver overrun,
UART receiver framing error - occurs if you configured invalid number of stop or data bits;
transmit timeout waiting for CTS,
transmit timeout waiting for DSR,
transmit timeout waiting for RLSD - occurs if you configured invalid hardware flow control or your serial interface cable isn't wired for hardware flow control
transmit queue is full - occurs if Serial Printer Logger can't send data to remote device;
break condition received
You can also set the program to initiate the serial interface at the specified time. On some old versions of the Windows NT operating system it could help to avoid the loss of data when the program has been working for a long time without restarting. Please use the "Additional options" tab (fig. 2.1.4)
Fig. 2.1.4 Additional options
Here you can also select the terminal emulation mode. In this mode the program will remove or interpret some special terminal sequences automatically.