winusb and visa device issue

[Jo-Jo]

I have a system I am working on that communicates with some custom hardware via USB. I used the NI driver wizard to create some visa drives, and perform USB RAW writes and reads, and everything was working great.  Unfortunately, I just found out that there is a whole other application written in C++ by someone else that also has to communicate with the same hardware on the same system. Their application uses WinUSB to communicate with the device, so currently the only way I know of to switch between the two applications is to uninstall the VISA drivers, and install the WinUSB drivers, or vice-versa, depending on which application one wants to use.  This obviously isn't going to work long-term.

I'm not sure how to fix this so that we can use both application on the machine without having to constantly change the drivers back and forth. I thought about trying to call WinUSB.dll using LabVIEW, but I'm afraid that might get a little complication. I figured I can't be the first one to run into a problem like this before, so before I start down the WinUSB road, I thought I would check to see if anyone has any better ideas. I'm afraid trying to get at the source, or in anyway changing, the C++ application is not an option.

Thoughts? Ideas? Is calling WinUSB in LabVIEW my best bet?

[rolfk]

---

 

Thoughts? Ideas? Is calling WinUSB in LabVIEW my best bet?

---

Most likely. Unless you have access to the source code of your other application and can change it to communicate to your device using VISA Raw. NI-VISA has a C API so it is technically possible.

Technically it is not so much WinUSB which is the likely problem but probably something in the application installation which registers WinUSB as the driver handler for your USB device resource. Except for filter drivers, which are chained into the driver chain by Window and for which Windows has a configurablle maximum limit of active filter drivers in the system, Windows only allows one driver to register for a specific device resource. So it would be technically enough to just change that registration entry to point to the currently desired driver.

However this registration API (SetupDI API and its friends) is quite cumbersome and the whole process is rather brittle as it easily can break with every new driver update. Also it would never allow to run both application in parallel, even if you make sure that they do not communicate to the device at the same time.

So calling WinUSB in LabVIEW is probably your safest bet. It won't be trivial, the WinUSB API is somewhat involved but it is definitely doable. The most difficult part is the implementation of your device protocol anyhow which you seem to have tackled already for the VISA raw mode, so I do not see real road blocks ahead, just some botherings about correct Call Library Node configurations

[Intaris]

LibUSB has a windows driver which allows combining a filter with actual communication.  You can install it and use LibUSB to communicate with your device without uninstalling the vendor's driver.  You will be pretty much low-level USB at that point though.  Of course only one process can access the device at a time.

Shane.

Edit: Hmm, it appears that LibUSB for Windows now also builds on WinUSB (it didn't last time I used it).  Don't think that'll actually bring anything in your case.  Just another layer of complexity.

[Jo-Jo]

So I have begun trying to use WinUSB, and I didn't get very far.  I can't seem to get the device to enumerate. I am using a working C++ application as a reference, and just trying to recreate it in LabVIEW, so I know the variables are correct.  The first dll call seems to be working properly. At least I get something back for the device info, and it looks right. I have attached some code.

Can anyone tell me why this doesn't return any DeviceInterfaceData?

[Intaris]

Can you check the error out of the DLL calls?

[Jo-Jo]

there is no LabVIEW error return, and calling GetLastError() doesn't return anything either.  This makes me think that there is just something wrong with the dll call I'm making, which is making is fail silently, rather than me just passing in bad parameter values. Unless there is some other initialization step I am missing, but I can't think of what it might be.

[Mentos]

Hello Jo-Jo,

I know this is an old thread but it is very relevant for me at the moment.

Any chance you can send me your VIs saved for LV2011 version ?

Thank you in advance,

Mentos

[Dennis_Knutson]

Use the Version Conversion board.