Troubleshooting RS232 Connections

June 23rd, 2005

From Monitor #83, a publication of Windmill Software, Ltd.

You’ve plugged your instrument into your computer’s COM port, installed your data acquisition software, but no data appears. You suspect it is a problem with your RS232 communications. What do you do?

1. Obtain RS232 Troubleshooting Software

Download comDebug, our free RS232 troubleshooting software.

2. Find Communication Details: Baud Rate etc.

Obtain all the information available about your instrument or device. You will need to know the baud rate, number of bits in the data byte and parity. If you have information about the stop bits then use it, otherwise set them to 2. This will at worse slow the message down slightly.

3. Send a Message

If you can persuade your device to send a message, perhaps a power on message or a message that can be initiated by a button press, then do so. This will verify your signal connections. At this stage you should select the no handshake option when setting up the COM Port. If you still can’t receive any data, you may have a COM port or a wiring error. Use comDebug’s COM Port Status window to check the state of the lines to and from the computer, and see points 4, 5 and 6 below.

4. Check the COM port is Working Correctly

This tip works if your instrument is a DTE computer type with a 9-pin connector. Disconnect the RS232 cable from your instrument. Check it has a socket on the free end. Unravel a paperclip, insert one end into the pin 1 hole on the cable socket and the other into the pin 2 hole. (Pin 1 is to the right of the long edge, pin 2 is next to it.) When you now send a message it should echo back to the computer and you can confirm that messages are arriving at your instrument.

5. Check the Cabling

If you suspect a wiring error, you could try contacting the manufacturer of your instrument to see if they sell the correct cable. Sartorius devices, for example, won’t work with a standard RS232 cable and you need to either purchase a cable from the company or re-wire the connections. If your instrument is a DTE computer type, you may need a Null Modem adaptor. Alternatively, you may want to try rewiring the cable connector yourself

When wiring the cable yourself, the first signals to connect are the ground, RXD and TXD. Try to establish, from your device’s documentation, which signal wire carries its output data — connect this to the computer’s RXD. The signal which inputs data to your device should be connected to the computer’s TXD. Don’t rely on the signal names, remember the signals can be either inputs or outputs depending on whether your device is a computer or modem type. It’s not unusual for Instrument Manuals to neglect this vital information, but you may be able to get a clue from other signals. For instance if the manual says that DTR is an output then the instrument should be a computer type. If on the other hand it says that DSR is an output then it should be a modem type. In fact if you know the direction of any one of the signals you should be able to deduce the rest. Beware when doing this: we have encountered manufacturers who change the names of the data signals when dealing with modem types - after all it must be confusing to tell a user that Transmitted Data is an input!

If the signals are correctly named then a computer to modem link connects TXD to TXD and RXD to RXD. A computer to computer link (more common when dealing with instruments) connects TXD to RXD and RXD to TXD. This crossed arrangement is sometimes called a Null Modem connection, and buying an adaptor may solve your wiring problems.

If all else fails you can determine which data signal is the output by measuring the unconnected data lines with a voltmeter or using one of the plugs with built in LED indicators which show the line state. The output signal will be at a definite negative voltage, properly -12 Volts or more. The input line will be close to 0 Volts. The only time this strategy will fail is if your device is of the multidrop variety. These only drive the output line for the duration of the transmitted message.

6. Set Hardware Handshaking or Flow Control

If you are confident that the signal wires are properly connected, but you still can’t retrieve a message from your instrument, you may need to tie the handshake lines.

Handshake arrangements can be used for two purposes. Firstly the computer can prevent the device from sending data when it is not able to receive it. Secondly the device can prevent the computer from sending data when it is not ready for it. The fact that your device comes equipped with inputs and outputs that can be used for handshaking is no guarantee that handshaking is needed. The signals are often provided simply because the processor used in the device provides them, so the manufacturer feels he may as well put them on the plug. It is usually best to start with the intention of tying any potential handshake lines to fixed voltages so that they do not affect operation. In fact many manufacturers add tying resistors to handshake lines so that if you do not want to use them you simply make no connection.

If you start with no handshaking what symptoms might indicate that it really is needed? Well one possibility is that the computer misses part of a message because its input buffer overflows. In COMIML the buffers are 3000 bytes long so you are unlikely to be bothered by this problem. The other possibility is that the device misses part of a message sent by the computer. This will presumably cause the device not to operate as desired.

If you do decide that handshaking must be used then the comDebug software uses DTR / CTS handshaking. This means that the computer uses its DTR output to indicate when it is able to receive data and its CTS input can be controlled by the device to prevent transmission of data from the computer. Once you select the hardware handshake option the state of the CTS input to the computer becomes important. When hardware handshake is not selected the CTS line state is ignored, the DTR output however is maintained permanently high so you can use it to tie unused inputs on your device.

7. Set Software Handshaking or Flow Control

XON\XOFF Handshaking is a software protocol that is often used to control data flow. Supposing that the computer were sending data to a device which could accept no more data for the time being - the device would send the single Xoff character to the computer which would stop sending data until it received an Xon character to restart transmission. The same arrangements would apply for the reverse direction of data flow. If your device requires this type of handshaking then simply select it in comDebug.

8. Other Ideas

If you’ve assured yourself that the cabling is fine the problem may be with the way the software is set up. Refer to your software’s user manual and check the configuration.

Entry Filed under: Data Acquisition, Test Equipment