Is it possible to receive COM port event when the COM port is closed?

Question

I'm on my laptop and unable to check this right now, I'm wondering if I open a COM2 connection, and add a receive event for COM2 port, then close the COM2 connection via "serial.Close()" in the program, will I still be able to receive a receive event on COM2 port? Let say if it can still receive, I think I will open the COM2 port connection at the receive event and read the data, can it be done this way?

    SerialPort serial = new SerialPort()
    {
        PortName = "com2",
        BaudRate = 9600,
        Handshake = System.IO.Ports.Handshake.None,
        Parity = Parity.None,
        DataBits = 8,
        StopBits = StopBits.One,
        ReadTimeout = 400,
        WriteTimeout = 200,
    };

 serial.DataReceived += new System.IO.Ports.SerialDataReceivedEventHandler(Receive);

    private void Receive(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
    {            
        using (SerialPort serialPort = serial)
        {                
            if (serialPort.IsOpen)
                serialPort.Close();
            try
            {
                serialPort.Open();
                received_data = serialPort.ReadExisting();
                Dispatcher.Invoke(DispatcherPriority.Send, new UpdateUiTextDelegate(WriteMyData), received_data);
            }
            catch (Exception ex)
            {
            }
            finally
            {
                if (serialPort != null)
                {
                    if (serialPort.IsOpen)
                    {
                        serialPort.Close();
                    }
                    Thread.Sleep(5);
                    //serialPort.Dispose();
                }
                Thread.Sleep(5);
            }
        }
    }


    public void SerialCmdSendByte(byte[] hexstring)
    {
        using (SerialPort serialPort = serial)
        {
            if (serialPort.IsOpen)
                serialPort.Close();
            try
            {
                serialPort.Open();


                foreach (byte hexval in hexstring)
                {
                    byte[] _hexval = new byte[] { hexval };
                    serialPort.Write(_hexval, 0, 1);
                    Thread.Sleep(3);
                }                 
            }
            catch (IOException ex)
            {
            }
            finally
            {
                if (serialPort != null)
                {
                    if (serialPort.IsOpen)
                    {
                        serialPort.Close();
                    }
                    Thread.Sleep(5);
                    //serialPort.Dispose();
                }
                Thread.Sleep(5);
            }
        }            
    }

The idea is to only open a connection when I want to send from C# program and close it straight-away, but the same COM port is actually need to listen for communication from PIC-based microcontroller. Currently we are having issue where previously the program never try to close connection (unlike above code), but sometimes the receiving part from PIC-based microcontroller works but the sending part from program doesnt work. This only happens sometime, as normally the program work just fine...

Restarting the system seem to reset this OK. So I was thinking making the code like above will help in my situation(to be able to send, and listen on same COM port)?

Answer 1

Unfortunately, no. Only 1 connection to the COM port can be open at a time.

If you have a device listening on that port, then nothing else will be able to send on it.

If you have access to the code that the microcontroller uses to listen on the device, you could always write something that allows you to send a message to the microcontroller and have that device send your COM message.

Otherwise, the only thing you could do is have the microcontroller stop listening on the port, send your message from your code, receive any response that comes back from sending your message, and then reenable the microcontroller's listen features.

EDIT:

Just a note about your code. The using statement is designed to dispose of an object after closing all of its connections when it goes out of scope.

In your code, you are creating a reference to your serial port instance in a using block. If this works as defined, that serial port instance will need to be instantiated before you can call it again.

Answer 2

As a complement to jp2code answer and since imagination is the limit, you might want to try a more "out of the box" solution, something similar to Man-In-The-Middle.

THIS POST might give you a better idea about what I'm talking about.

Answer 3

You cannot communicate or listen on serial port when the port is closed. So the code you have written is absolutely wrong.

Ideally you should not turn off the COM port.

Following can be the reasons why your communication fails.

1.This one seems to be the most probable answer: If the COM port is not closed properly in the previous run, the communication will not take place. In this case you have to reset the system. This takes place when the system gets crashed in between.

2. When the connectors are not tight, this can occur.

3. Check if the ground connections are proper.

Let me know if you need help in changing the code.

Answer 4

8 years later... so this is probably of no use to the original poster, BUT...

This is probably an excellent use-case for the Reactive Extensions for .NET. Rx can be used to wrap a serial port and expose an IObservable<char> over the received data, which can then have multiple subscribers and be filtered in various ways using LINQ operators and expressions.

I have a whole library built around this concept that abstracts the serial port away entirely and replaces it with the concept of a Communications Channel, which can be implemented with a serial port or some other device (such as a network connection, or a device simulator). Applications don't need to know what type of device they are talking to, so it is really easy to build apps that can work with different types of connection. Configuration is stored as a connection string (an idea borrowed from SQL Server). It also has a mechanism for implementing command-response protocols based on the idea of a transaction, with the benefit of being thread-safe and keeping commands and responses in sync. I've used it with good results in several commercial projects.