Comm32 Logo
Home Button   

Topic:   Port lockup
By: jtbPosted on: Jan 3 2011 at 03:21:01 PM
Hi, thanks for the quick replies to my other issues.
We have been testing the ocx as a replacement for the mscomm32 control. Our application is transferring binary data at 9600 baud, using a usb serial port with the newest FTDI driver. We have a issue that occasionally the port "hiccups" and although remains available according to Windows, the software loses the connection. Using your ocx and the OutputEx function, we are reliably able to detect this condition (OutputEx will return 0 when we attempt to send data), and trigger the recovery code. The recovery code sets .PortOpen = False, then tries to reopen the port. If we test this by simply unplugging the usb, then plugging it back in, everything works great. But at the client site, the call to close the port never returns. Our software cannot be closed by Windows Task Manager, nor killed from the process list - the only way to restore the use of the port is to restart Windows.
We had the same issue with MSComm32, though we could not reliably detect the condition, this is what sent us in search of a replacement in the first place.
I was testing with version 3.2u of your control, and using two stop bits as a workaround for the mark parity issue. Today I upgraded to version 3.2v with the mark parity working and one stop bit, I will let you know if the issue still happens in this version.

By: Support Posted on: Jan 3 2011 at 07:45:21 PM
When you physically remove a USB/rs232 then windows would normally see that the port has gone and it would be removed from device manager and the driver instance in memory would be destroyed and your application would be able to close and attempt to reopen the port.

But you say that on your client site windows still thinks the port exists (still visible in device manager?)

In that case I'd suggest that you disconnecting the USB on your computer is not an exact way to duplicate the problem that's happening on the customer site.

Is your client using the same hardware/driver etc as you are?

Can you think of any other way to reproduce the problem that your client is experiencing. if I can reproduce it here I may be able to avoid/fix it.

By: jtbPosted on: Jan 5 2011 at 01:38:44 PM
Having done some more tests, the port lockup occurs only after the usb/serial connection has been idle for 20 minutes or more. Could the usb port "go to sleep" because of the inactivity? If so, how can we deal with this in software? This would also explain the fact that this problem happens in only one out of 10 systems, all of which use the same hardware and driver.

By: SupportPosted on: Jan 5 2011 at 03:04:27 PM
Sounds like power saving mode.

Check in the computer bios whether there's any power saving mode related to network, USB, blutooth etc. If there is then switch it off.

If the computer is a branded machine with the manufacturer's own configuration utility then also look in there for energy saving mode.

By: jtbPosted on: Jan 14 2011 at 02:56:26 PM
Hi, an update on the port lockup issue: it was not caused by power saving mode. The cause of the lockup is wi-fi interference on the USB line. We are modifying our hardware to reset the USB when this occurs, and are testing the software to make sure it makes a full recovery once the hardware is reset.