nrHid and property NameFriendly of HID device

[luben.hristov]

Hi,

I made a project where every 2 ms I get a new packet of data from the HID device (Atmel 90USB1286). Because I need to make a lot of calculations and to display the data onto a complex form I use an independent thread to process the data and send each 20ms a message (from the thread) to the main thread to display the data. The nrHid1AfterReceive is only placing the data into temporary array and then is triggering semaphore to tell the processing thread that new data arrived - ReleaseSemaphore(hSemDebugDataReceived,  1, nil);

I found that very often when I connect / disconnect the device I can't detect my device through the Hid.NameFriendly. But the VendorID and ProductID are always correct. Instead of returning the correct string of the HID I get "HID-compliant device". The result is that I can't use reliably the .NameFriendly property to connect to the hID.

If this will help somehow to locate the problem I found the following:

1. Once the .NameFriendly stops reporting correctly restarting the program can't solve the problem. You need to disconnect the USB device, exit the program and then connect HID and start the program.

2. The problem appears mainly during active HID communication, if there is no HID traffic everything looks OK

3. I found also that once the problem appears the HidDemo project supplied with the nrHid is not able to detect the NameFriendly correctly.

4. I used before some old nrHid trial versions and I never got such misbehaviour. The problems appeared with the purchasing of the new Pro version.

Thank you

Best regards
Luben

[hid1]

For current version, EnumFullMode = True?

Old version not have this property, FullMode was  always true.

[luben.hristov]

Hi Hid1,

I set it but the problem remains  :(. I noticed that if EnumFullMode = True I have to avoid calling nrHid1.WMDeviceChange(Msg).

As I said if the problem occurs you can close the program and call the HidDemo supplied with the nrHid and you'll see that the effect is still there - the demo can not recognize the nameFriendly of the HID. Only disconnecting the HID device from the PC and also closing down the programs that use the HID can recover the situation.

I have a feeling that some HID thread remains active until the device is connected, this explains why if the problem appears it could be cleraed ONLY after disconnecting both the HID device and closing the program. If it matters I'm using Windows XP SP3 and Delphi2010.

Best regards,
Luben

[luben.hristov]

Hi,

As I mention that in some cases the NameFriendly is not working properly in nrHid. I found that once the nrHid "flips" and stops repoting the correct NameFriendly the nrHid.Update takes too long - couple of seconds! It could be connected to this problem or it could be a completely new problem.

Some ideas from where comes the Update delay?

--- Updated----

I found that if the HID is sending permanently data the problem with the NameFriendly occurs. If the HID stops sending data and the name is reported correctly without any need to disconnect/connect the HID device from the cable. It seems that the constant flood of data is somehow preventing the nrHid component to correctly read the nameFriendly.


Best regards,
Luben

[pjdu]

how to get a new packet of data every 2 ms ?
where is the setting?

[COPA1]

Are you sure that it isn't an OS/μC issue?
Check the OS device properties during the problem. Is the string correct?

[COPA1]

Hi,
Did you manage to solve the problem?
I am afraid that I am exactly in your situation. But appeared more rarely: μC microchip 18Fxxxx , nrComm Lib v9.23 ,BCB6, WinXP SP3. Using TnrHid  in the standard way (main vcl thread).
(Nice situation…)

With the chance, I wish to all a happy, healthy and prosperous new year… The same to  the Roman too…  (His hard work simplifies so much our life!…)