Comm32 Logo
Home Button   

Topic:   USB to Serial converters - Any known problems?
By: Mike in BRPosted on: Oct 11 2010 at 04:18:46 PM
I am having different serial communication problems on different computers using the same compiled VB6 code, talking to the same Prolific-chipset (PL-2303H/X/HX) USB-serial converter, talking to the same servo controller. I suspect it may be a conflict between USB drivers (same on both machines) and the individual PC's USB hardware. I have an IOGEAR GUC232A USB-serial device that I will try next (Prolific chipset, but different drivers). If that doesn't work, I will try an FTDI chipset based converter from Digikey or Mouser.
I am communicating at 57600,8,n,1. My messages consist of short 10-byte commands with 3-32 byte responses.

Any other suggestions?

By: SupportPosted on: Oct 11 2010 at 08:00:11 PM
You said you have problems but you don't say what the problems are?

If you can describe the problems and the conditions under which the problems are occuring then we may be able to help.

To answer your first question - no, there really shouldn't be any problem with the prolific chipset.

By: Mike in BRPosted on: Oct 11 2010 at 10:12:35 PM
I am having a difficult time replicating the problems described by my customer. Using an older Dell 630 ATG and a newer Dell 640 ATG. One of the errors described to me is that when the USB cable was removed and reinserted into another USB port on 640ATG, the old instance would still be listed in Device manager. So now two com ports show, whereas only one is valid. Although not an issue with Comm32, this may be related to other USB issues my customer seemed to experience on the 640ATG. On the older 630 ATG the servo controller will initialize properly every time, whereas on the newer 640ATG, occasional failures happen when initializing. Initializing consists of sending a short serial command on the com port. The 630 (older) works perfectly except during certain operations of driving a servo motor in one direction, which locks the software. The 640 ATG does not have this lockup issue. To move the motor, a single command is issued to the controller, which handles the movement. The VB6 code polls the status of the ongoing move through the serial port to check when move is complete. On the 640 ATG the program would not close correctly and sometimes give BSOD, but it would close correctly on the 630 ATG. I am setting portopen to false (if already open) before unloading the form. I don't know why it does not work consistently from one computer to the next.

By: SupportPosted on: Oct 11 2010 at 10:31:59 PM
I'm thinking the problem where you remove a usb serial port but the port remains in device manager may be related to a specific brand of usb adapter. I never saw the problem before. Is it a specific brand. Or any brand ?

Using USB there can be situations where a computer will crash if you close the com port while data is still waiting to be sent. For example if data is in the transmit buffer but is being held back by flow control. Give us a couple of days and we'll see if we can reproduce/isolate this problem and release a fix.

I see you're running at 57600 Does it need to run that fast?

Try adjusting the com port fifo. That's in device manager, com port advanced settings. Leave fifo enabled but slide the fifo sliders right down to 1. (may not be available with usb ports but look anyway)