USB virtual COM port disconnect?

[Jim Wagner]

Greetings folks -

The project I am working on uses multiple USB virtual COM ports. As the code configures itself, it checks whether or not the serial port for each channel can be opened, When it is opened, then it proceeds with link validation. That is working well.

My puzzle, now, is how to tell if a link is broken after it was opened. In the case of a USB virtual COM port, I would expect the port to close itself when the USB link is broken. There does not seem to be a way to tell whether or not a port is open without trying to open it. Yes, you can periodically try to open it, but that makes little sense while it is operating and I fear that may mess up an already established open condition. Or, is that what you have to do?

Many thanks

Jim

James Wagner
Oregon Research Electronics
http://www.orelectronics.net <http://www.orelectronics.net/>




_______________________________________________

Xojo forum:

https://forum.xojo.com/

[James Sentman]

Unfortunately with a Virtual COM port you’re at the mercy of the USB/Serial driver if it will send you an error or not. It also depends on where the error happens in the chain. In my experience standard disconnects from someone just pulling the plug when the port is open will either give you a nice error from the error event of the Serial control or it will kernel panic the OS. More recent MacOS versions seem more stable than they used to be about that, but I think it still can crash the entire machine. This is bad also because noise on the USB line or ground loops and other problems can cause the same disconnect/reconnect event and possibly a crash. in years past I had a server with a USB/Serial adaptor on it and behind the wall where it was installed was the air handler for my furnace. For several months whenever the blower motor would start up it would somehow cause multiple load/unload cycles of the USB/Serial driver and about half the time kernel panic the machine. LIke I said things are better now ;) Mostly…

The drivers for FTDI based adaptors are very different than the Keyspan drivers or the other ones that are available now. The latest MacOS versions even contain a built in driver for the FTDI based adaptors. They are the most reliable in my experience and I recommend those to everyone as they seem to be able to give me errors rather than just go deaf or panic the machine. Even so getting an error is not guaranteed under every circumstance.

But then there are other errors on the serial side of the line that won’t generate any errors at all.

The only truly reliable way to know if a link is working is to actually attempt to communicate with whatever device is on the other side. If it answers then you’re communicating ;) Though I did implement for a while an attempt to open the ports I already thought were open. If they returned an error that meant they were in use by the other serial control and as far as the system knew. If the open succeeded then the other connection had dropped without an error and I could pass the new serial reference into that class which would continue to run. I think this worked, but it was impossible to test as I was never able to generate the situation where the link would be dropped without getting an error or a crash. I had user reports of something that sounded like that, but I could never make it happen so I don’t know if the system releases the port so that it can be re-opened again when whatever the error was happened or not.

Post by Jim Wagner
The project I am working on uses multiple USB virtual COM ports. As the code configures itself, it checks whether or not the serial port for each channel can be opened, When it is opened, then it proceeds with link validation. That is working well.
My puzzle, now, is how to tell if a link is broken after it was opened. In the case of a USB virtual COM port, I would expect the port to close itself when the USB link is broken. There does not seem to be a way to tell whether or not a port is open without trying to open it. Yes, you can periodically try to open it, but that makes little sense while it is operating and I fear that may mess up an already established open condition. Or, is that what you have to do?

Thanks,
James


James Sentman http://www.PlanetaryGear.org http://MacHomeAutomation.com




_________________________________

[Jim Wagner]

Thanks, James -

I figured that if anyone knew about this, it would be you. I had long suspected that “keep alive” exchanges would help and you have pretty much re-enforced that idea. Since I have control over both ends of this channel, its not a big issue right now.

Really appreciate your observations and suggestions.

Jim

James Wagner
Oregon Research Electronics
http://www.orelectronics.net <http://www.orelectronics.net/>

Post by James Sentman
Unfortunately with a Virtual COM port you’re at the mercy of the USB/Serial driver if it will send you an error or not. It also depends on where the error happens in the chain. In my experience standard disconnects from someone just pulling the plug when the port is open will either give you a nice error from the error event of the Serial control or it will kernel panic the OS. More recent MacOS versions seem more stable than they used to be about that, but I think it still can crash the entire machine. This is bad also because noise on the USB line or ground loops and other problems can cause the same disconnect/reconnect event and possibly a crash. in years past I had a server with a USB/Serial adaptor on it and behind the wall where it was installed was the air handler for my furnace. For several months whenever the blower motor would start up it would somehow cause multiple load/unload cycles of the USB/Serial driver and about half the time kernel panic the machine. LIke I said things are better now ;) Mostly…
The drivers for FTDI based adaptors are very different than the Keyspan drivers or the other ones that are available now. The latest MacOS versions even contain a built in driver for the FTDI based adaptors. They are the most reliable in my experience and I recommend those to everyone as they seem to be able to give me errors rather than just go deaf or panic the machine. Even so getting an error is not guaranteed under every circumstance.
But then there are other errors on the serial side of the line that won’t generate any errors at all.
The only truly reliable way to know if a link is working is to actually attempt to communicate with whatever device is on the other side. If it answers then you’re communicating ;) Though I did implement for a while an attempt to open the ports I already thought were open. If they returned an error that meant they were in use by the other serial control and as far as the system knew. If the open succeeded then the other connection had dropped without an error and I could pass the new serial reference into that class which would continue to run. I think this worked, but it was impossible to test as I was never able to generate the situation where the link would be dropped without getting an error or a crash. I had user reports of something that sounded like that, but I could never make it happen so I don’t know if the system releases the port so that it can be re-opened again when whatever the error was happened or not.

Post by Jim Wagner
The project I am working on uses multiple USB virtual COM ports. As the code configures itself, it checks whether or not the serial port for each channel can be opened, When it is opened, then it proceeds with link validation. That is working well.
My puzzle, now, is how to tell if a link is broken after it was opened. In the case of a USB virtual COM port, I would expect the port to close itself when the USB link is broken. There does not seem to be a way to tell whether or not a port is open without trying to open it. Yes, you can periodically try to open it, but that makes little sense while it is operating and I fear that may mess up an already established open condition. Or, is that what you have to do?

Thanks,
James
James Sentman http://www.PlanetaryGear.org http://MacHomeAutomation.com
_______________________________________________
https://forum.xojo.com/

_______________________________________________

Xojo forum:

h