LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Need Example Code to Interface with a USB HID compliant Device

I am trying to interface to a HID complient uC using Labview.  I've seen several forum posts directing users to use the VISA driver Wizard and use Raw USB, but there seems like there should be a better way since the device already uses the HID driver and adding a second driver would complicate things.  I'm not looking for the easy way out as I know nothing about USB protocol, I just don't want to redo what I think might already be out there.

 

Thank you

0 Kudos
Message 1 of 34
(15,262 Views)

Hi NateM,

 

Take a look at this document; I think it will be very helpful.  The section regarding HID compliant devices answers your question.  The best way to communicate with your HID compliant device is to use the hid.dll. You can call into the DLL using LabVIEW's Call Library Function Node.

 

I hope that helps,

Daniel Dorroh
National Instruments
Message 2 of 34
(15,224 Views)

Depending on the level of functionality you want to implement calling hid.dll with the Call Library Node may not be trivial at all and not enough too. If you want some user friendly device selection you likely will have to call some SetupDI API calls as well to enumerate the avialable HID devices and give the user a convinient selection list to choose the device from. Unless you wire the VID/PID combination into your code or require the user to provide them, but the second I would consider highly user unfriendly as most don't know what a VID and PID is.

 

While access to the hid.dll is fairly straightforward, the SetupDI API is a pain to interface with the Call Library Node. In that case it is likely much easier to create a seperate DLL wrapper in C first, or go directly with the VISA variant, eventhough you have to implement the HID protocol yourself in LabVIEW when going the VISA route.

 

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 3 of 34
(15,203 Views)

Thank you for the reply.  I agree that using the HID.dll is the best option.  I was asking for example code because I cannot find any documentation for the HID.dll that would help set up the Call Library Function Node input/output parameters.  I don't know what arguments the HID.dll is expecting or what arguments it is returning. My hope was that since HID is very common, this information would be available somewhere in these forums. 

 

 

Thank you.

0 Kudos
Message 4 of 34
(15,179 Views)

Well agreeing that hid.dll is the best option is easy. Making it work however very difficult. Smiley Surprised I looked at some projects from the past where I had to interface to a HID device, and hid.dll is definitely not the holy grail. In fact it is only a very small part of any kind of library that wants to interface to a HID device. A much larger part consists of acess to SetupDI... functions in setupapi.dll to enumerate the installed HID devices and find the one of interest, retrieve the device name of it, then calling standard WinAPI functions CreateFile() with that name to open the device driver, then using ReadFile() and WriteFile() to actually transfer the raw binary data. After that you call CloseHandle() to close the device. There are several dozen Windows API calls to do, some of them rather complicated and a complete pain in the ass to do with the Call Library node.

 

What I ended up in all cases, was writing an intermediate DLL in C, that did all this and exposed a small API to LabVIEW to be used. Unfortunately I can't post any of that code here. But I can not recommend this to anyone not able to write some real C code. Thelow level C programming knowledge required to be able to interface some of those APIs with the Call Library Node directly is in fact greater than to simply writing some C code to call those APIs. That and the fact that maintenance of a C code file to access such APIs is much easier and cleaner than a LabVIEW VI doing horrondous memory acrobatics in order to be able to create the complicated data structures that some of the APIs require left to me no doubt which road to take.

 

In any case you will have to read and understand C code and C API documentation in order to go the hid.dll path. One place to start would be http://www.lvr.com/hidpage.htm to get some idea, then from there look for some C code samples, and finally read the MSDN documentation about the various APIs involved. If you then find that writing a DLL in C to interface to these APIs is to complicated I can only advise you to forget to want to try to interface these APIs with the Call Library Node. The resulting code is much more time consuming both in creating and debugging it and also in later maintenance, than doing it all in C in a DLL.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 5 of 34
(15,164 Views)

An easy to use USB HID Host driver for LabVIEW is the AHID.DLL. Just a couple of functions like

 

- Init()

- Register()

- Read()

- Write()

- Find()

- Attached()

 

do the job.

 

It comes with several example applications for Visual Studio and LabVIEW. Have a look at http://www.ahidlib.com.

Message 6 of 34
(15,023 Views)

Thank you for all the input.  I ended gettig some help with writing an intermediate .NET dll and used that to interface to LabVIEW.  

 

Thank you.

0 Kudos
Message 7 of 34
(15,019 Views)

Hi Nate,

 

is it possible to share your .net dll you have written and the labview code? I am also want to communicate to usb hid device.

 

Thanks a lot.

 

Best regards,

Michael

0 Kudos
Message 8 of 34
(14,066 Views)

Sorry.  Our code group considers it proprietary.  I really wish there was something commercially available as my solution is still unfinished.

0 Kudos
Message 9 of 34
(14,027 Views)

Micha,

 

The posted ahidlib link from Sam Potter is as easy as it can get. It still doesn't solve the device specific communication itself but that is something you have to do on your own as it is .. yes indeed ... device specific. HID is simply a standard in how to structure the downlink and uplink to the device. What de individual bytes in those two streams really mean is very specific to each device, except in the case of standard HID devices like mice and keyboards.

 

Most likely that is also the reason why Nate couldn't share his implementation since it implements the device specific protocol handling too, which his company most likely considers proprietary.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 10 of 34
(14,008 Views)