09-18-2012 03:51 PM
Did you take look at the following Knowledge Base item:
http://digital.ni.com/public.nsf/allkb/611475F9BE62881E86256FDC0062B1BB?OpenDocument
09-19-2012 10:18 AM
Hello,
I used the devcon commands and it has helped me run my program multiple times before crashing. It still didn’t completely solve the problem. Therefore, I incorporated a switch on the USB VCC line (it's the same as unplugging and plugging the USB cable from the PC).
Also, I've contacted NI support and no definite fix yet. If they do come up with one I'll make sure to post the solution.
09-20-2012 04:56 PM
On Windows Vista and 7, the USB stack appears to mishandle programming how split-transactions are handled. Split transactions only occur when using an EHCI (high speed) host controller with a high-speed hub and a full/low-speed device. NI does not make any low-speed (1.5Mbps) USB devices. This does not occur when plugging a full-speed device directly into a port on the host machine, because hardware will automatically switch to an UHCI/OHCI companion host controller.
This probably happens in Windows Server 2008, since it shares similar OS components with Windows Vista and 7.
This does not happen in Windows XP (and probably also not in Server 2003).
We have found a work around to this issue. If we only use 1 IRP for data transfer (instead of the default of using multiple IRPs), then we do not see this issue. This is likely an issue in the EHCI support code in Windows Vista and 7 improperly handling multiply queued IRPs.
This change allows you to work around the issue by not using multiple outstanding IRPs. However, it has the downside of potentially limiting data transfer throughput. For this reason, we did not make this change a default. Even with a single IRP, a USB-6009 should be able to sustain 50 kS/s (100 kB/s).
You will need to set the channel property AI.UsbXferReqCount to 1 to fix this as fgrootent posted earlier in this thread. See the attached VI "test6009WakaWakaWakaFixy.vi" for an example to use with your USB-6008.
09-21-2012 08:00 AM
Hello,
Yes I did take a look at the link, however, the error I'm getting is different (error-50405). I incorporated the code within the link to avoid buffer overflow in the future.
Thanks,