none
Serial Port Does not Close Properly

    Question

  •  

    Hi, I've tried using the System.IO.SerialPort class to read / write from a portable device I have through COM Port.  The device I have will echo back the text I send.  All of my codes and results run fine for the first time, but when I run my program for the second time I can't read anything off the COM Port.

     

    Code Block

    SerialPort port = new System.IO.Ports.SerialPort("COM4");

    if (!this.port.IsOpen)
          this.port.Open();

     

    port.Write("Some Text\r\n");
    DateTime now = DateTime.Now;
    TimeSpan t = DateTime.Now.Subtract(now);
    while (true && t.TotalSeconds < 10)
     {
        t = DateTime.Now.Subtract(now);
        Response += port.ReadExisting();
        if (Response.IndexOf("\r\n") >= 0)
           break;
    }

    this.port.Close();

    this.port.Dispose();

     

    When my program runs the second time, it always return empty string until the timer I set has reached (10 seconds).  I have to unplug the device and plug it back again in order for it to work again.  I've tried just calling the Close(), but still has the same problem.  Is there anything I'm missing in order to close the COM Port and release its resource completely? 

     

    BTW, the device is working fine with Hyper Terminal - I can send and receive text fine, and I can connect / disconnect many times and get consistant results.

     

    Thanks!

    Saturday, January 19, 2008 2:51 AM

Answers

  • Have you remembered a delay betweeen port close and port re-open? SerialPort has a background thread, which needs some time (200 - 500 mS) to close down before you are allowed to reopen the port - use e.g. an Application.DoEvents() statement followed by a Sleep(200) statement.

     

    One of the most common mistakes is to open and close the port all the time (for each transmission). Open the port when you start your application or select the COM port (COM1, COM2 etc.) and don't close it again until you change the COM port or terminate your application. It is not necessary to dispose the port.

     

    What version of .Net are you using? SerialPort in .Net 3.5 seems to be so full of errors that it may be regarded as useless.

    Sunday, January 20, 2008 10:12 AM

All replies

  • Have you remembered a delay betweeen port close and port re-open? SerialPort has a background thread, which needs some time (200 - 500 mS) to close down before you are allowed to reopen the port - use e.g. an Application.DoEvents() statement followed by a Sleep(200) statement.

     

    One of the most common mistakes is to open and close the port all the time (for each transmission). Open the port when you start your application or select the COM port (COM1, COM2 etc.) and don't close it again until you change the COM port or terminate your application. It is not necessary to dispose the port.

     

    What version of .Net are you using? SerialPort in .Net 3.5 seems to be so full of errors that it may be regarded as useless.

    Sunday, January 20, 2008 10:12 AM
  • Thanks for your suggestion, Carsten.  However, after the disconnect, I've closed the program and waited a few minutes, then start the program and connect again, I still got the same problem.  I will not be able to connect again until I unplug and plug-in the hardware again.  Don't you think that the COM Port's background thread will be closed already after a few minutes?   When I was running this in the debugger, the SerialPort.Open() method executed fine without any exceptions.

     

    Thursday, January 24, 2008 2:01 AM
  • When you close the port, the background thread will close down as fast as the preemptive multithreading allows. If you block all the high priority jobs on the UI thread e.g. by means af Sleep(), 200-500 mS is usually enough.

     

    I think that the problem is in the other end of the line. There is no way to detect an unplugged RS232 line so it cannot affect anything in your software, and in case of a USB-Serial converter, an unhandled exception is thrown and the program crashes. Maybe your device is powered from some of the modem control signals so that when you unplug it, it is reset. You can try to loop the transmitter back to the received and see if you still have the problems. If not, the problem is in the connected device.

    Thursday, January 24, 2008 8:13 AM
  •  

    Carsten, I don't really understand what you mean by "loop the transmitter back".  However, I've tried using HyperTerminal with my device and I was able to connect & disconnects many times (without physcally unplugging the device) and the device still function without any problem.  So I don't think the device is causing the problem itself.

    Thursday, January 24, 2008 10:40 PM
  • With loop-back I mean that the TX line is connected directly to the RX line (hardware connection in the plug), so that you will receive all you send.

     

    I can see from your new question that you are using a USB-Serial converter. In .Net 2.0 there is a bug that if you disconnect the device, an unhandled exception is thrown. Microsoft has tried to fix that in .Net 3.5 and as far as I know (?) also in SP1 for .Net 2.0, but without great success. I have seen reports that the bug is still present, but has coursed other issues. Maybe you need to reset SerialPort by means of a disconnection to release a lock?

     

    What version of .Net are you using? As I wrote before, SerialPort in .Net 3.5 seems so full of errors that it may be regarded as useless. Hyperterminal does not use SerialPort. Therefore it works ;-)

     

    This is actually a very serious problem using .Net, which I have never thought about before. Since you rely on standard classes, which may be changed without notice, you never know if your program will work after a .Net upgrade like SP1. I think that I will write my own class when I get a little more time.

     

    Friday, January 25, 2008 8:04 AM
  • I'm using .Net 2.0.  From what I've seen so far, I guess my only real solution is to implement the serial class myself.  Do you know if there are any alternative 3rd party solution available?

     

    Tuesday, January 29, 2008 2:57 AM
  • .Net 2.0 should be OK. Have you tried your program on a normal serial port - not a USB-serial converter? USB-serial converters are known for lots of problems and bad drivers.

     

    Tuesday, January 29, 2008 7:56 AM