Problem about GetHidGUID .... (Not Solved)

[vgbraymond]

Hi! I made a simple VI as in the picture attached.

When I done with this, the first time I ran it, it took less than a second and then gave a number, I suppose it is a GUID, then the program ended. Then I clicked Run again, it took a rather long time, a few second and than the program was down! My questions are...

1. why would it be down in a second run?

2. I displayed the GUID in the number indicator, but is it not big enough to store the whole GUID? If not big enough, what should I use?

Raymond

[MikeS81]

Hi Raymond,

the original funcion has no return value. See this link.

Mike

[vgbraymond]

Hi! Mike,

  What about this one?

  What should I expect in the array 2? How could I understand the two numbers there?

Raymond

[MikeS81]

Hi Raymond,

from the msdn, these are the "device interface GUIDs" connect/found in your system.

Mike

[vgbraymond]

I was really confused.

Firstly.. A guid should have 16 byte but I can store up to 8 byte (64bit) in one element, so my GUID here should be incomplete... How should I deal with this?

Secondly.. I got two elements at the first time, and then I tried to unplug my mouse and (I am using a notebook so I have my mouse pad) run this program again, I still got two elements in the array.. why would this happen?

Raymond

[rolfk · Accepted solution]

---

vgbraymond wrote:

I was really confused.

Firstly.. A guid should have 16 byte but I can store up to 8 byte (64bit) in one element, so my GUID here should be incomplete... How should I deal with this?

Secondly.. I got two elements at the first time, and then I tried to unplug my mouse and (I am using a notebook so I have my mouse pad) run this program again, I still got two elements in the array.. why would this happen?

Raymond

---

Firstly, you allocate an array of 16 int32, not 16 int8 (bytes), then you pass it to the Call Library Node to a parameter that has long long array type. long long however is 64 bits so LabVIEW converts your 16 int32 into 16 int64 to pass to the function. That function fills in 16 bytes and returns. I hope you can see why you get what you get.

Secondly the GUID returned is simply a GUID that you can use to enumerate the HID devices in your system. It is NOT the device enumeration itself. For that you need to do a lot more work in terms of calling several more Windows APIs among which some like SetupDiGetClassDevs(), SetupDiEnumDeviceInterfaces(), SetupDiDestroyDeviceInfoList() and HID_FindDevice().

Message Edited by rolfk on 10-13-2009 08:24 AM

[vgbraymond]

Thanks! Combining what you said in this reply and my experiment on changing the data-type of numeric array in my VI, I understood the result.

Thanks Mike and Rolf!!

[glogloglo]

I am trying to enumerate HID devices too, but the function setupdienumdeviceinterfaces does not return anyone.

Can someone help me?

Thanks,

 Andrew

[rolfk]

---

glogloglo wrote:

I am trying to enumerate HID devices too, but the function setupdienumdeviceinterfaces does not return anyone.

Can someone help me?

Thanks,

 Andrew

---

Are you sure that the Wiimote registers itself as a HID device??? It could be but it could just as well be that it uses its own custom USB class.

And there are some problems with your VI. The hWndParent parameter to the SetupDiGetClassDevs is not a string but simply a pointer sized integer (32bit integer for pre LabVIEW 8.6) and should be a 0 value if you do not have a valid window handle.

Similar with the second parameter to SetupDiEnumDeviceInterfaces. You call it elements and pass an empty string to it. However it is a data structure and for them the only valid parameter is either a NULL pointer or a valid structure block. Passing in an empty string is NOT equal to passing in a NULL pointer. Either construct a valid data structure and pass its pointer to this parameter or reconfigure it to be a pointer sized integer and pass a 0 value to it. As it is now, the function interprets that parameter to be a valid structure but only the first byte of it is defined by LabVIEW and set to 0. All the rest is random and sure enough 99.999999% to define something that Windows can never find a device for.

And last but not least all these functions can fail. This is either indicated by returning INVALID_HANDLE_VALUE (-1 or 0xFFFFFFFF) for SetupDiGetClassDevs or FALSE (0) by the other functions. In that case you should generate an apropriate error and NOT call any other functions, except possibly the SetupDiDestroyDeviceInfoList if at least the SetupDiGetClassDevs was successful. Unfortunately since LabVIEW is multithreaded there is no way to retrieve the GetLastError() value in the case of a failure indication of either of these fucntions. So you onlyknow that an erorr happened but not which one. To really makes this whole thing robust and fully functions including getting meaningful erro codes from GetLastError() you would have to create an external DLL and implement everything in there and then call its API through the Call Library Node. 

Message Edited by rolfk on 10-25-2009 03:34 PM

[glogloglo]

Thank you Rolfk.

I have solved, the problem was in the array lenght (the working array is an array of lenght 28, the first element has a value of 28). I can now receive and send data with the device.

The last problem is that I miss the original bluetooth stack; I have installed the demo version of bluesoleil, but I believe that the original widcom 4.0 can work as well, so I would try to re-install it before paying for bluesoleil. The problem is that the only available driver from the manufacturer if widcomm 5.1 that does not work with my device because it does not allow to skip the secure code entry when pairing with the device. I can't find the old 4.0 version of widcomm.

Any suggestion?

Thanks again,

 Andrew