Method to determine when a Serial Port (COM Port) is disconnected

Forgive me for being a bit lazy on this, but I did try a couple of things, but no joy.

I have a serial port setup procedure that works fine, but the procedure can take some time. During that time, if the usb cable is disconnected for some reason, and the user presses a “record” button, then the recording will go ahead but no data will be recorded.

Therefore, when the user selects “record”, the first thing that needs to happen is the software, as a final check, ensures there is still a valid “hardware” connection.

This situation is unlikely, but I would like to ensure that the user is alerted in case it does happen.

As a simple example I’ve tried: Serial.Open:

If Serial1.Open Then Serial1.Write("c") MsgBox ("All good - Proceed as usual") Else MsgBox ("There is a Serial Port connection issue. Perhaps if you spent more time learning code instead of fluffing around with irrelevant 'fancy' user interface issues, then these sorts of issues wouldn't happen. But of course, as usual, you'll never read this message because it will never show anyway. Well, good luck to you.") End If

When I disconnect the usb cable, the recording proceeds anyway.

I thought Serial.Open means if the serial port is not open then the “Else” statement should follow - but obviously not.

Well, I think it makes sense. The Serial Port thinks it’s open. If there is some kind of simple query/response from the device you’ll be able to tell if it’s disconnected. Otherwise, I don’t think there’s much you can do.

what i do for this scenario is to do a scan for available ports, select one and try to connect to be sure its valid, the name of the port is stored stored in a local variable of some type, then the port is disconnected.

you do not need to connect to the port until just before the data is sent, connecting before hand is not really much use.

then at the point the user wants access i scan the available ports again, if the one selected at the start is still available the port connection is tried, if the error returned is zero then its all good.

with this you can unplug any adaptor at any time and you know if its available when need or not.

i am working this on MAC, Pi and win.

Thanks Bob.

I agree that the simple query/response is probably the safest and superior way to go. Unfortunately that will only work with MY Hardware Device. My software allows users to connect their own devices given some generic requirements.

ie. The attached hardware device transmits data in grams, and the sample rate is known.

I want to make the software as generic as possible to allow users to purchase and use the software recording function without having to purchase the hardware device - perhaps a bit generous? I’m dealing in an area where there are no standards between software and hardware connections.

Nevertheless, I will code the method as you suggest for my own learning experience. Most of the programs I have written that deal with serial communications have been reading from the serial port, not writing. So this part will be fun and interesting.

[quote=406506:@Mark Carlton]what i do for this scenario is to do a scan for available ports, select one and try to connect to be sure its valid, the name of the port is stored stored in a local variable of some type, then the port is disconnected.

you do not need to connect to the port until just before the data is sent, connecting before hand is not really much use.

then at the point the user wants access i scan the available ports again, if the one selected at the start is still available the port connection is tried, if the error returned is zero then its all good.

with this you can unplug any adaptor at any time and you know if its available when need or not.

i am working this on MAC, Pi and win.[/quote]

Thanks Mark.

What you are suggesting reminds me of a tutorial I read about 2yrs ago when I first started reading about Xojo Serial and writing this application. (gulp!!! that’s a long time ago :))

I think it was a bar-code reader example. I disregarded that method because it wasn’t appropriate. But now I believe that it’s worthwhile pursuing and likely the only other way to detect the com port disconnect than Bob’s query/response method.

Although, I’ve heard of weird situations (WIN7) where com ports can change their name depending on the order they are plugged in. I’ll have to check it out.

The reality is, is that if users are pulling usb plugs in and out for no reason, then they should not be using my software!!

Perhaps I could change the message box to:

[code]If Serial1.Open Then
Serial1.Write(“c”)
MsgBox (“All good - Proceed as usual”)
Else
MsgBox ("Well, well, well, this is the third time you’ve been mucking around with the usb plugs and have caused a connection issue - will you never learn? For your own safety, I have disabled the program. You will have to log in to the website and pass a stringent test before getting a new license code.

btw. Some people get much enjoyment and kudos from stamp collecting and knitting, etc. (not that there’s anything wrong with that). Perhaps using this software and device is not really your thing?.. you know, just sayin’…
End If[/code]

teeheee :slight_smile:

What I will be doing:
I’m going to use both Bob and Mark’s methods. This should hopefully cover all situations. This is top of my list at the moment and will take some doing, but I reckon it’s worthwhile and the best way forward.

Cheers.

are you talking about the user unplugging the USB/Serial adaptor? Or unplugging the serial line from the adaptor and leaving it plugged in? If you unplug a USB Serial adaptor then the serial port really shouldn’t be listed in the serial port list anymore. It might take a fraction of a second for the kernel module to unload, but if you scan the array of available ports rather than try to open the port you’ve already gotten an object for that might be more reliable. Once you’ve created the object then who knows how it behaves when trying to open a port that was unplugged. I imagine the proper throwing of errors would be up to the driver and they can be funky.

I have a similar situation on the Mac where I want the list of available ports to be dynamic and update as they unplug or plug in new USB/Serial devices. For that I used the MBS plugins and the USB Events system so that when a usb plug or unplug happens I get an event and can rebuild my popup based on the most recent availability of things.

If you’re talking about an actual on the motherboard com port on a windows machine or unplugging the data cable and not the USB cable then there isn’t any way to know if that comes unplugged that isn’t reliant on the device sending something upon connection or responding to some command you can send to them.