Serial COM port communications has always been one of my favorite topics. Ever since I was 15 I was writing code to communicate with electronics my Dad or I made.
Unfortunately VS.NET does not have a serial communications framework in place. So this tutorial explains how to easily communicate through a serial port using the MSComm OCX that is included with VB in Visual Studio 6 (and previous versions). You must have at least the ActiveX components of VS6 installed in order to use MSComm because it is a licensed control.
Required: MSComm.ocx installed with Visual Studio 6.
Note: To obtain MSComm.ocx and it's associated licensing, you can do a custom install of Visual Studio 6 and just install the ActiveX components (about 5MB).
You must add the control to a form instead of just instantiating the control straight from code because it requires special OCX state information and a developing license be included in your program's assembly. By drawing it onto a form, VS.NET handles these for you.
Here is a quick overview of some important properties of the MSComm control.
The one single event that the com control calls is the OnComm event whenever something happens. To use this, be sure to set RThreshold = 1 and check the InBufferCount inside your event. Use com.CommEvent for more information as to why the OnComm event was fired. Example:
If you are making your own serial interface/protocol, you really must have a good standard in place. Serial data flows into the com port byte by byte and must be buffered and parsed correctly. Think of it this way, if a terminal sent your computer "Hello World" it may come in as four OnComm triggers: "H", "ello", " Wo", and "rld"
The best protocols are usually a mix of these methods.
Here are three simple protocol techniques:
Pin Assignments
The Null Modem Adapter
There is a standard serial adapter called a Null Modem adapter (obtainable at most Radio Shacks) that crosses over the TX and RX lines to enable you to connect two computer together. This is important because if you wire one com port directly into another, the transmit lines (TX) will both be connected together and both ports will be trying to transmit on the same line (similarly for the RX lines). A null modem usually crosses over the flow control lines too. Here is a layout diagram if you want to make your own:
Physical Pins Layouts
Here is a diagram of the pin layout for the DB9 and DB25 connectors. Most connectors already have little tiny numbers next to the pins.
To use this:
In most cases you will want to set RThreshold = 1 to fire the OnComm event every time some data is received. But there are cases when it would be easier to use a loop to wait for and capture incoming data.
My favorite scenario is in creating pseudo plug & play port detection for my devices. When my app starts it scans the com ports for my device. Here is some example code to find the port that my device is on. See that by setting RThreshold = 0 and disabling the OnComm event, I can quickly and easily have a completely self contained bit of code to preform the task. Be sure to always including time outs to prevent getting caught in an endless loop.
These are frequent issues that arise. If you are experiencing difficulty sending or receiving data, please review these topics and methods for a solution.
Sending Unusual Data w/ Byte Arrays
Generally using the text/string method is easiest, but it can cause unpredictable results when dealing with many special characters. In this case you should use byte arrays. Ex: com.Output = new byte[] {0, 0x41, (byte) 'A', 255};
Receiving Unusual Data w/ Byte Arrays
As with sending, most of the time data comes in through the com port in any form, not just letters A-Z and numbers. If you use a terminal program and see strange characters, you will need to use byte arrays. Here's how:
Remember, data is not received in nice, easy to manage packets. If your devices sends "Hello World", it could come in through the com.Input property in several steps, like "He", "llo ", "W", "orld". This can make it difficult to process incoming data. Here are some techniques to receiving data:
Unfortunately VS.NET does not have a serial communications framework in place. So this tutorial explains how to easily communicate through a serial port using the MSComm OCX that is included with VB in Visual Studio 6 (and previous versions). You must have at least the ActiveX components of VS6 installed in order to use MSComm because it is a licensed control.
Required: MSComm.ocx installed with Visual Studio 6.
Note: To obtain MSComm.ocx and it's associated licensing, you can do a custom install of Visual Studio 6 and just install the ActiveX components (about 5MB).
Adding the MSComm Control |
You must add the control to a form instead of just instantiating the control straight from code because it requires special OCX state information and a developing license be included in your program's assembly. By drawing it onto a form, VS.NET handles these for you.
- Create a new Windows Form
- Add the MSComm COM/OCX Control to your "Windows Forms"
- Right Click on the Toolbox
- Choose "Customize Toolbox..."
- Select and add the "Microsoft Communications Control"
- Draw the new control onto your form (Telephone icon)
Properties and Event Info |
Here is a quick overview of some important properties of the MSComm control.
- com.CommPort
Sets or gets the computer's serial port to be used.
- com.PortOpen
Opens or closes the serial port.
- com.RThreshold
Sets how many characters should be received before firing the OnComm event. Set to 0 to disable event calling. Set to 1 to fire OnComm every time a character is received.
- com.InputMode
On of the MSCommLib.InputModeConstants constants to specify either sending/receiving text strings or byte arrays. Defaults to text which is easier to work with but not as reliable as byte arrays.
- com.Settings
Used to setup the port in the format "baud,p,d,s" where baud = baud rate, p = parity, d = # data bits, and s = # stop bits. Ex: com.Settings = "9600,n,8,1"
- com.Handshaking
On of the MSCommLib.HandshakeConstants constants to specify the type of handshaking: none, RTS/CTS hardware hs, and/or XOn/XOff software hs
- com.InBufferCount
Returns the number of characters waiting in the receive buffer.
- com.Input
Returns and removes a stream of data from the receive buffer. Used to check for data waiting. Returns a string if in text mode or byte array if in binary/byte mode.
- com.Output
Writes a stream of data to the transmit buffer. Ex: com.Output = "Hello" sends "Hello" through the serial port.
- com.CommEvent
Returns a MSCommLib.CommEventConstants, MSCommLib.ErrorConstants, or MSCommLib.OnCommConstants constant representing the most recent error or event that occurred. Check this in the OnComm event.
- com.NullDiscard
If true, the serial control will ignore all 0x00 (null) characters come in. You will usually want to disable this so you can receive 0x00 since it may be important.
- com.InputLen
The number of characters the Input property reads from the receive buffer. Setting InputLen to 0 reads the entire contents of the receive buffer when com.Input is used.
The one single event that the com control calls is the OnComm event whenever something happens. To use this, be sure to set RThreshold = 1 and check the InBufferCount inside your event. Use com.CommEvent for more information as to why the OnComm event was fired. Example:
public MyForm() |
Protocol Development |
If you are making your own serial interface/protocol, you really must have a good standard in place. Serial data flows into the com port byte by byte and must be buffered and parsed correctly. Think of it this way, if a terminal sent your computer "Hello World" it may come in as four OnComm triggers: "H", "ello", " Wo", and "rld"
The best protocols are usually a mix of these methods.
Here are three simple protocol techniques:
- Beginning and Ending ("Start" & "Stop") Codes
This is good for sending text as it lets everybody know when text starts and ends. You simply tack on a non-normal byte at the beginning and end of the text. For example, you'd use '---' to signify the start of the string and '===' to signify the end. So you would use: com.Output = "---Hello World===";
- Fixed Length Codes
Used for specific commands. You can create your own codes to send and specify what they mean. Say I want to control the lighting in a house, I'd setup a protocol of commands like this:
1st byte = House Code, 2nd byte = Light Code, 3rd byte = On or Off (0 for off, 1 for on)
So to turn on the 11th light in my house (house code #3) I'd use:
com.Output = new byte[] {3, 11, 0};
- Prefixed Data Packet
This is probably the most common and flexible but requires the most coding. Just prefix your data packet with the length of the data. The prefix must be a fixed size, such as two bytes which would allow a data packet of up to 65,535 bytes. Then the receiver knows how much data is in the packet because it always takes the first two bytes and uses the rest as the data packet.
Example: com.Output = ((char) 00) + ((char) 11) + "Hello World";
Physical Port Layout and the Null Modem |
Pin Assignments
9-pin | 25-pin | Assignment |
Sheild | 1 | Case Ground |
1 | 8 | DCD (Data Carrier Detect) |
2 | 3 | RX (Receive Data) |
3 | 2 | TX (Transmit Data) |
4 | 20 | DTR (Data Terminal Ready) |
5 | 7 | GND (Signal Ground) |
6 | 6 | DSR (Data Set Ready) |
7 | 4 | RTS (Request To Send) |
8 | 5 | CTS (Clear To Send) |
9 | 22 | RI (Ring Indicator) |
The Null Modem Adapter
There is a standard serial adapter called a Null Modem adapter (obtainable at most Radio Shacks) that crosses over the TX and RX lines to enable you to connect two computer together. This is important because if you wire one com port directly into another, the transmit lines (TX) will both be connected together and both ports will be trying to transmit on the same line (similarly for the RX lines). A null modem usually crosses over the flow control lines too. Here is a layout diagram if you want to make your own:
DB9 Female to DB9 Female |
Physical Pins Layouts
Here is a diagram of the pin layout for the DB9 and DB25 connectors. Most connectors already have little tiny numbers next to the pins.
DB9 Male (Pin Side) DB9 Female (Pin Side) |
Example Code |
To use this:
- Create a new form
- Add the AxMSCommLib control and name it "com"
- Add a Rich Text Box named "rtfTerminal"
- Put the constructor code below in the form's constructor
- Add the rest of the code. Make sure the settings are right for your system.
- Have another computer with a null modem connecting the two and a terminal programming (such as Tera Term Pro) running.
// Constructor for Form with an AxMSCommLib control on it named "com" |
Advanced Topic: Loop Based vs Event Based Receiving |
In most cases you will want to set RThreshold = 1 to fire the OnComm event every time some data is received. But there are cases when it would be easier to use a loop to wait for and capture incoming data.
My favorite scenario is in creating pseudo plug & play port detection for my devices. When my app starts it scans the com ports for my device. Here is some example code to find the port that my device is on. See that by setting RThreshold = 0 and disabling the OnComm event, I can quickly and easily have a completely self contained bit of code to preform the task. Be sure to always including time outs to prevent getting caught in an endless loop.
public short FindDevicePort() |
Techniques for Sending & Receiving Data |
These are frequent issues that arise. If you are experiencing difficulty sending or receiving data, please review these topics and methods for a solution.
Sending Unusual Data w/ Byte Arrays
Generally using the text/string method is easiest, but it can cause unpredictable results when dealing with many special characters. In this case you should use byte arrays. Ex: com.Output = new byte[] {0, 0x41, (byte) 'A', 255};
Receiving Unusual Data w/ Byte Arrays
As with sending, most of the time data comes in through the com port in any form, not just letters A-Z and numbers. If you use a terminal program and see strange characters, you will need to use byte arrays. Here's how:
- Setup com.Input for receiving byte arrays. Change your "com.InputMode" to:
com.InputMode = MSCommLib.InputModeConstants.comInputModeBinary;
- When receiving data, store into a byte array.
Here is an example OnComm event:
private void OnComm(object sender, EventArgs e) // MSCommLib OnComm Event Handler {
// Receive data into a byte array, good for any type of data
byte[] indata = (byte[]) com.Input;
// Show each byte received in the "Output" window
foreach (byte b in indata)
Console.WriteLine("Byte Data: " + b);
}
Remember, data is not received in nice, easy to manage packets. If your devices sends "Hello World", it could come in through the com.Input property in several steps, like "He", "llo ", "W", "orld". This can make it difficult to process incoming data. Here are some techniques to receiving data:
- Use "Start" & "Stop" Tokens
This is by far the preferred method of the three. If you can design your protocol, use one of the methods described above, such as the "Start" and "Stop" codes. Prefix and suffix the data with known codes to signify the beginning and ends of a data packet. Then when data comes in, buffer it and just check the buffer. The example below is with strings since they are generally easier to work with.
// We'll use Regular Expressions to match the data 'start'/'stop' tokens using System.Text.RegularExpressions;
// Used to buffer the incoming serial data
private string ComBuffer = "";
private void OnComm(object sender, EventArgs e) // MSCommLib OnComm Event Handler {
// Add to the buffer the incoming data
ComBuffer += (string) com.Input;
// Example regular expression test string
// string ComBuffer = "trash---Hello World===trash---How Are You?===trash";
// Build a regular expression to match data that
// starts with '---' and ends with '==='
Regex r = new Regex("---.*?===");
// Cycle through the matches
for (Match m = r.Match(ComBuffer); m.Success; m = m.NextMatch())
{
// Display the result to the 'Output' debug window
Console.WriteLine(m.Value);
// Remove the find from the string buffer
ComBuffer = ComBuffer.Replace(m.Value, "");
}
}
- Time Interval Packets, Using a Timer
If you know that data will be coming in at defined time intervals, say there is always at least a second before the next set of data, then use a timer method. If you used a loop you could easily tie up system resources. Again you will need to buffer the data.
// Use the system timers library using System.Timers;
// Used to buffer the incoming serial data
private string ComBuffer = "";
// Create a new timer for serial data watching
private Timer tmrWaitData = new Timer();
// You will need to initialize the timer
private void ExtraInitCode()
{
// Set the timer interval to one second
tmrWaitData.Interval = 1000;
// Attach the timer tick event handler
tmrWaitData.Elapsed += new ElapsedEventHandler(tmrWaitData_Elapsed);
}
private void OnComm(object sender, EventArgs e) // MSCommLib OnComm Event Handler {
// Check to see if data is waiting
if (com.InBufferCount > 0)
{
// Add to the buffer the incoming data
ComBuffer += (string) com.Input;
// Reset the timer
tmrWaitData.Stop();
tmrWaitData.Start();
}
}
private void tmrWaitData_Elapsed(object sender, ElapsedEventArgs e)
{
// Show to the 'Output' window the data that was received
Console.WriteLine("Data Packet: " + ComBuffer);
// Stop the timer now that this data packet
// has been successfully received
tmrWaitData.Stop();
}
- Limit the Incoming Buffer Trigger
If you know that data will always come in at a fixed amount, for example 10 characters, you can change the com.RThreshold value to trigger the OnComm event only when that amount has been received. Normally you would want OnComm to be triggered whenever any data is received, but you can change this if you are careful that all your data comes in the same amount of bytes/characters.
回复Comments
作者:
{commentrecontent}