Can we RESET a USB connection (windows XP) from LabVIEW?

[Jed_Davidow]

We have a LabVIEW 2009 applicaiton that comunicated with an FTDI USB device using the VCP (Virtual COM port driver).

Due to what we believe are noise issues on the power lines (And we are working on alleviating this), the COM port occaisionally "dissapears".  As far as we can tell, it has nothing to do with the simple VISA communication in the program.

The only way we have been able to deal with this is to have a user unplug and then re-plug in the USB line, physically.

Can we simulate this with a windows function?

We have seen that this happens more often when we have a hub with a KB and mouse plugged into another port on the root USB hub (The PC only has one usb root hub and no expansion).  Is there anything we can do to prevent this?

Thanks.  Any info on how to deal with some of the USB "Black Magic" that we see would be much appreciated. 

[smercurio_fc]

You might try plugging the device into another USB port. Some ports may not provide enough power for your device. You could also try using an external USB hub - these typically provide more power than those built into PCs.

As for "resetting" the USB port, you can try to use devcon for that. This has been asked frequently over at the LabVIEW forums.

[Ryan_G_EE]

I would like to second this question. I am trying to communicate with several pieces of bench-top lab equipment, (O-scope, DC supply, eLoad and some FTDI based USB to I2C dongles) and am having intermittant connectivity issues with most of them. I am working on tracking down the source of the loss of communication, but in the mean time I would like to find some way to reset the USB port programatically, as part of the error handling routine. If there is any way to do this, please let me know!

I am currently working with FTDI's proprietary DLL, which may provide a solution for the FTDI based devices that I am trying to communicate with (TBD). However I would really like to find a universal solution, instead of relying on a proprietary DLL...if there is some kind of VISA command to talk to the USB controller on the host PC or something, it might be ideal.

FWIW, I need something that works for all versions of Windows, XP and newer. Currently, I think all of our machines are running W7, 64-bit, but I would prefer a solution that is portable enough to move to any Windows based PC.

[nyc_(is_out_of_here)]

We have 20 or so USB instruments on one test station.

It is best to find a USB hub that is highly-rated on Newegg.

[Ryan_G_EE]

deleted

[Ryan_G_EE]

Sorry for the last post. Apparently the forums won't let me delete it properly, nor edit it again.

Anyway, I resolved the USB issue I was having. The code was attempting to concurrently initialize multiple instruments, and apparently the host USB controller didn't like that. I solved the problem by sequencing the initialization on a per-instrument basis.

[JSlavic]

R. Gibson....I have a similar problem.  I have various devices, some connected directly to the PC, others through external self-powered hubs.  Some devices are self powered, others are self powered.  I'm talking to the VCP as well as calling the dll directly.  On Win7, when I call the dll, it locks up the driver and I can no longer talk via the com ports.  Any ideas?  This worked in XP but seems to be a windows problem.

[Ryan_G_EE]

Are you opening and subsequently closing each resource before opening and closing the next resource sequentially? If you are opening each resource and leaving it open, and then trying to access another resource, it could be causing your problem?

[JSlavic]

Yes, opening and closing each handle then the comport on each call. Here's what FTDI has, try it.  I'm talking to the same device in a loopback using each method.  Works connected directly, through the Dell monitor hub or other off the shelf hubs, after running the d2xx example, the comport is no longer available. 

As you suggest, its acting like the handle is left open, which may be the case but I still can't find a work around.

[Ryan_G_EE]

Out of curiosity, try running the attached code. It loops around, simply opening and closing the FTDI handle. See if it works or not for you, or if the resource still locks up. This works fine on my machine, both direct and through an external hub.