Implementing and Debugging RS232 serial connections
A short tutorial on serial interface communications
 |
There are thousands of devices available with an RS232 serial interface including laboratory instrumentation, quality and process control devices, measuring instruments, meters, gauges, scales, industrial controllers, sensors, PLCs, etc. Although RS232 connections are meant to be simple, they can be extremely frustrating to debug. There are several aspects of each type of connection where things can go wrong including hardware and cabling problems, communications settings mismatches and communications protocol problems. Fortunately, there are a number of inexpensive (and sometimes free) software tools that you can use to quickly figure out what is going wrong. Once you have everything connected and communicating properly, you are then faced with the problem of developing the application that reads in data from the device and does something useful with it. Again, there are plenty of tools widely available to make this part of the job relatively quick and painless.
Selecting the correct COM port
The first step in debugging RS232 connections is to make sure that you are connected to the correct COM port on your PC and that you have the right cable for connecting the device to your PC. If you are unsure of which serial port you are connected to, you can look in the Windows Device Manager under the “Ports (COM & LPT)” section to see a list of all the ports that are installed in your system – including Virtual COM ports created by add-on serial adapters. You can then try setting up whatever communications software you are using to connect to each available COM port to see if you can communicate with the device that is connected to the port.
Using the right cable
There are two primary types of RS232 cable — “modem cables” and “Null modem cables”. The most basic RS232 cable has three wires — a transmit line, a receive line and a signal ground. It is also possible for a serial cable to have other “handshaking” lines in the cable as well. The extra lines are used to control the flow of data through the connection. Whether you need these extra lines or not will depend on the device that you are trying to communicate with. If the device uses any type of “hardware handshaking” (A.K.A. RTS/CTS or DTR/DSR flow control) then these lines must be present in the cable otherwise you may not be able to communicate with the device.
A Modem Cable has the wires in the cable going straight through whereas a Null modem cable has the transmit and receive lines (as well as the handshaking lines) crossed in the cable. If you use the wrong cable, you will never be able to communicate. A device called a “Null Modem Adapter” is a small connector that slips in line with the cable connection to cross the transmit and receive lines (and the handshaking lines) in the cable. You can pick one up at any computer or office supply store for around $5.00. If you are not sure about what type of cable your particular hardware uses (or what type of cable you have), having a Null modem adapter handy is always a good idea. Try communicating with the device without the Null modem adapter in the line and, if you are unsuccessful, try again with the Null modem adapter in the line. If the cable that you are using was not provided with the device that you are trying to communicate with, you may need to contact the manufacturer of the device to make sure that you obtain the correct cable for connecting the device to a PC. To determine what type of cable you have, use an Ohmmeter or circuit tester to test the cable. If you get continuity from pin 2 on one end of the cable to pin 2 on the other end of the cable, then you have a modem cable. If you get continuity from pin 2 on one end to pin 3 on the other end then you have a Null modem cable.
Setting the correct communications parameters
RS232 ports must also be configured to use a set of communications parameters including the “Baud Rate”, “Parity”, number of “Data Bits”, number of “Stop Bits” and possibly a “Flow Control” setting. If any of the settings in the PC communications software do not match the
 |
settings that the device is configured to use, then you will probably not be able to communicate with the device. The best thing to do is to read the manual or contact the manufacturer of the hardware that you are using to find out exactly what parameters you should set in the communication software that you are using and make sure that they match exactly.
Note: You normally do not need to set any communications parameters for a COM port in the Windows Device Manager because most serial communication software will set the communications parameters directly overriding any settings in the Device Manager.
In some cases, a manufacturer of a device will provide software that is designed to communicate with their particular hardware. They may not be willing to tell you what parameters you need in order to communicate with their hardware using other communications programs. If you have a software program that can successfully communicate with a particular device however you want to use a different software package (or if you want to write your own software), you can snoop in on what the other software is doing using a good serial port “sniffer” program. Microsoft provides an excellent (free) one called PortMon that you can download from: http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx
PortMon is a utility that will report activity on all the serial ports on your PC. It will tell you what parameters are used to open the COM port as well as what data is being sent and received through the port. PortMon generally provides way more information than most people would ever need to know, however it is still an invaluable tool to have in your toolbox.
Understanding and implementing the protocol used for communicating with the device
Most serial devices use very simple protocols for communicating over the RS232 port. The simplest devices might have a button that you press to transmit data to a PC. More commonly, a device will require that you send it some sort of text command that will “prompt” the device to send back some data. The majority of devices will also transmit all data in a text format that is easily understandable and readable in any text editor. The most difficult devices to work with use complex communications protocol that might require you to calculate checksums, send Ack or Nak responses or require that you convert data received from the device from binary values.
In all cases, it is extremely important that you fully understand the particular protocol that your device uses. There are no standards that dictate how a particular device or class of devices must work. Because of this, you may need to dig into the users manual for the device or contact its manufacturer to find out exactly how it works. At the very least, you need to know what is required to get the device to transmit its data (i.e. any commands that you need to send to it) as well as what the data should look like after it is sent back from the device (and how to interpret the data).
With simple text devices you should be able to test your connections using the HyperTerminal software that comes with Windows (located in your Accessories folder). HyperTerminal is a general “terminal emulation” program that will allow you to open connections to COM ports and send and receive data. Characters that you type on the keyboard get sent out the serial port and data that comes back is displayed in the HyperTerminal window.?
Implementing serial communications applications
Once you have all the connection problems sorted out, the next step is to develop an application to implement the sending and receiving of data to or from the serial device. If you are a programmer and you intend to develop an application using C/C++, Visual Basic, .NET, Delphi, PowerBuilder or some other full-blown Windows application development platform, you have plenty of tools available. All of the Microsoft development platforms not only provide simple components or classes for serial communications, they also come with sample source code that demonstrates how to use them. For example, Visual Basic 6 comes with the MSComm ActiveX control and the MSTerm sample application. The .NET platform (Framework 2 and above) has a “SerialPort” class and there are several good examples of how to use it both on the Microsoft MSDN web site as well as on other .NET developer web sites. If the development platform that you are using does not come with built in serial communications tools but it supports ActiveX components, you can also purchase (or download a freeware) 3rd party serial communications ActiveX component and drop it into your application. A freeware serial communications ActiveX component called NETCommOCX can be downloaded from: http://hardandsoftware.com
If you are more ambitious, you can also write your own code to talk directly to the serial port through the Windows API although this approach is generally much more complex than using a fully debugged off-the-shelf component. If you search the web for “serial communications sample source code” you will find hundreds of excellent examples for all the most popular development platforms.
If you are not a software developer or you do not want to go to the trouble or expense of developing a stand-alone application, another approach you might take is to use a tool like WinWedge from TAL Technologies (http://www.taltech.com/products/winwedge.html). WinWedge is an executable program that is designed to communicate with most typical serial devices and feed data from the devices directly (and in real-time) to other Windows programs like Excel or Access. WinWedge has a number of features including full data parsing, filtering and formatting capabilities as well as output capabilities that would let you both send and receive serial data directly from within other programs. For example, Microsoft Excel generally has more than enough capabilities for processing data that is typically sent from most serial devices (performing statistical functions, graphing and charting of data, etc.) however it does not have the ability to transmit or receive data directly from a device connected to a serial port. WinWedge basically provides the serial communications link and gets the data from the device directly into the spreadsheet (or any other application) without having to write any code.
If you run into trouble use the web. If you have connection problems or questions about a particular device that you want to communicate with or if you need tools to help you in the application development phase, a quick search on Google or the MSDN web site will more than likely uncover a solution.
Thomas Lutz is President of TAL Technologies. He may be reached at [email protected].
