 |
|
|
|
Topic: USB serial port disconnecting
|
| By: jtb | Posted on: Dec 28 2010 at 10:06:15 PM | | Hi, we have another small issue with Comm32.ocx. We are using a usb-serial adaptor to connect to our device. Under MSComm32, if the usb was disconnected while the serial port was open, an error would be generated when the Output method was called. Trapping this error would allow us to attempt to close and re-open the port. With Comm32, no error or exception is generated, so once the port is physically reconnected, data exchange does not resume because the logical port needs to be closed and reopened. We have worked around this by calling the PortExists method before sending data, however we are concerned that this may add unnecessary delay to our application. | |
| By: Support | Posted on: Dec 29 2010 at 06:21:10 PM | The PortExists( ) function is quite fast. It's simply an API call that returns pretty much instantly. It doesn't actually test any hardware it just 'asks' windows if the port exists. With physical ports and USB it appears to be pretty much instant. Try doing it 10000 times in a loop and you shouldn't have to wait long.
However, with some devices such as virtual ports/bluetooth devices it's not100% reliable because windows will sometimes claim that the port does exist even when it's disconnected. Windows appears to operate here on a (long) timeout so does not consider such a device to be gone until it's been out of range (disconnected) for quite some time.
I have seen that error you mention on some projects where I've used MSComm in the past but in my tests today I couldn't get MSComm32 to generate the error. I wanted to trap the error so that I could see what error code was triggered. I used a prolific usb adapter but just couldn't reproduce the error with mscomm.
Because it's not consistent, even with MSComm32, I wouldn't depend on that error to detect if the port has been disconnected.
Try one of these solutions
First idea might be to simply check the OutBufferCount property before sending data. If you wait for that to be zero before sending more data then you'll know pretty soon if your data isn't being sent - If the port has disconnected then all of your data will simply sit in the outbuffer not going anywhere.
That would only work if the ParalelEnable property is True. I mention that because the next solutions would only work if it was false.
Another idea - If you'd rather see a trap-able error - make sure you're using version 3.2v (3.2.0.95) or above. Set ParallelEnable=False and then Comm32 will fire a runtime error 8010 if the port was unavailable. Also make sure you've set small TxTimeouts otherwise it may take a while before the Output returns and fires the error.
If you are NOT using the OnComm event to send data (ie You're not responding to the evSend event) then you can use the OutputEx function instead of the Output property.
OutputEx is a function which returns the number of bytes sent. Set ParallelEnable=False and send your data as:-
NumBytesSent = .OutputEx("SOMEDATA")
return value ought to be 0 if the port was disconnected.(remember to set ParallelEnable=False)
| |
| By: jtb | Posted on: Dec 31 2010 at 02:57:05 PM | Thanks for your response.
I do have ParallelEnable set to false, but no trappable error occurs. I will try using the OutputEx function. I have version 3.2U (3.2.0.94), I don't see where I can download 3.2V, is this version available yet? | |
| By: Support | Posted on: Dec 31 2010 at 05:23:32 PM | Get the current download from the download page. That should be 3.2v even though that page mentions 3.2.0.94 it should be 3.2.0.95
| |
|
