Matt Fitzgibbons

I can't seem to find if VISA 3.0 supports LV6 anywhere. But VISA is basically a language-agnostic API. You could theoretically install VISA 4.0 (which definately doesn't support LV6), create a DLL (or shared object on UNIXy systems) in C exposing the VISA functions you want, then call this DLL in LV6. The VISA 'support' that you hear about is whether or not NI already has VIs for your version of VISA and LabVIEW. But by wrapping the API in a DLL, you can use it in 'unsupported' languages (i.e. older versions of LabVIEW). Also, you may be able to use a different interface. We use VISA to communicate to a tds3012b over TCP/IP, and it worked quite well when we were using LV6. I don't know your particular scope, but thought I'd mention another option. -Matt

Sorry it's taken me so long; I've been working on other projects. The descriptors in question had the incorrect length. The bLength field should be the number of bytes in the string, not in the entire descriptor. A handy program from Microsoft called USBView.exe exposed the bug. Apparently your original hypothesis that 3.1 was more lenient was correct. -Matt

As it turns out, it was the string descriptors that MAX didn't like. I turned those off, and now the device works. More debugging to do, but at least I know why....

I haven't actually tried an uncontaminated box, as I don't have one available (sigh...). I definately need to, though. I'll talk to our IT guy and see if I can make it happen. Thanks, Matt

If by frame you mean transfer in USB-speak, I actually had a very similar problem. I believe it was a synchro issue and was fortunately able to restructure my messages to make the synchro explicit. Which one? We're always looking for alternatives. None of these look very suspicious to me (nor do the changes for the other versions). It seems the problem is not with the communication between the device and the host, but VISA failing to recognize that the device is attached to the system. The enumeration is as expected. But VISA doesn't send any messages to the device. The VIs I have written just give me an 0xBFFF0011 (insufficient location information) error, as if the device were not attached to the system. In 3.1 the communication is correct. My thought as well. Thanks for your help. -Matt

Since my first post, I tried VISA 3.6 and I got the same thing. I wonder if it's an upgrade issue? (Although the box with 8.2 and VISA 4.0 had a new install but the same problem... so probably not). Also, a previous programmer on the project was working on a WDM driver that seems to have vestigal remains on both the boxes, and I've read about driver precedence breaking VISA drivers. It seems like this would break 3.1 as well as 3.6 and 4.0, though. The Device Manager also definately shows the correct driver in all cases. Finally, re: the 3.4 revision--are there any points of the spec on which the newer VISA is particularaly picky? I inherited the USB standard requests from the aforementioned previous programmer, and have found a couple cases where it wasn't handling a standard request that VISA was expecting it to handle (one of the EP status requests, IIRC). Any suggestions on where to look first? Still stumped. -Matt

I've got a USB device with custom firmware. It's pretty generic bulk transfer. I've been using the device with VISA 3.1 in RAW mode with no problems... until my boss decides it's time to update to VISA 4.0. I used the tutorial here to create a new INF. The device is even showing up in the Device Manager with the new driver. But neither MAX nor VISAIC list the device. Help! I'm using two separate WinXPsp2 machines, both with VISA 4.0; one has LV 7.1, the other LV 8.20. I've tried many permutations on reinstalling, uninstalling, and restarting. I've sucessfully downgraded to 3.1, so I know the device is not at fault. Any suggestions on what to try next? I'll gladly post any more information that might help. -Matt