03-04-2014 01:00 AM - edited 03-04-2014 01:01 AM
Hello Rolf,
thanks for your reply.
I tried ahid an it is very easy and simple. But the free version is time limited. I need the hid communication for a private project, so I am not interested in paying for a license.
I found an alternative, which uses the mcHID.dll (see http://forums.ni.com/t5/LabVIEW/How-to-configure-the-call-library-function-using-a-dll-for-HID/m-p/2...). It is as easy as ahid. But the problem is, that labview (I use 2012) becomes totaly unstable and crashes several times.
Now I did it by using classic usb raw and it also works for me. I am reading the temperature values of an usb temperature sensor (http://www.diamex.de/dxshop/USB-Temperatur-Sensor-Tester-fuer-DS18B20). But after around 150 values, the communication becomes disordered. I am not sure, what the problem is. With ahid, I never had this problem, so I think solution has to be find in labview usb raw communication.
Best regards,
Michael
03-04-2014 01:15 AM - edited 03-04-2014 01:15 AM
If it gets unstable with mcHID that would point to one of two possible reasons:
1) You made some mistake in configuring the Call Library Node. The more trivial mistakes are datatype mismatches of function parameters. The most common mistake however is to not initialize output buffer parameters (to a big enough size) so the DLL corrupts memory when trying to return data in them.
2) The DLL itself does unruly things somewhere that fell through the cracks during testing but make themselves apparent in LabVIEW, since LabVIEW is typically a bigger application so an unruly memory access easily can destroy something in memory that sooner or later lets LabVIEW trip over its feet.
03-04-2014 02:39 AM
Hi Rolf,
that sounds interesting.
>> The most common mistake however is to not initialize output buffer parameters (to a big enough size) so the DLL corrupts memory when trying to return data in them.
How do I initialize buffer for the dll?
Thanks a lot.
Best regards,
Michael
03-04-2014 02:52 AM
My actual code using mcHID is very simple (see attachment).
03-04-2014 04:47 AM - edited 03-04-2014 05:08 AM
@MichaGue_01 wrote:
Hi Rolf,
that sounds interesting.
>> The most common mistake however is to not initialize output buffer parameters (to a big enough size) so the DLL corrupts memory when trying to return data in them.
How do I initialize buffer for the dll?
Well assume you have a function like this:
int read_data(HANDLE handle, char *buf, int len);
The casual LabVIEW developer is usually tempted to just declare that function in the Call Library Node and pass it an empty array of U8 elements as second parameter since in LabVIEW you don't usually worry about the correct array size preallocation at all. But for C this is totally bad and will not work.
Instead you need to preallocate an array big enough for the function to fill in its data. In this case the caller would tell the function how big the array is with the third parameter. So use an Initialize Array node to allocate an array with len elements and pass this to the second parameter, passing the len number in the third.
Alternatively you can also just pass in a useful len value and configure the second parameter in the Call Library Node to have a minimum size equal or bigger to the len parameter. But I prefer the explicit Initialize Array allocation as it is directly clear to the reviewer that the array allocation has been taken care off and how, without the need to open the Call Library Node configuration dialog.
However your mcHID.dll seems to expect to communicate with the host application through its main window message loop. That is not so trivial to do in LabVIEW although there are ways to do that with an example called Windows Message Queue Library. But its implementation in an application is rather complicated and it doesn't work for every possible message type. I'm not sure how tolerant mcHID is about being passed an invalid NULL host window.
HIDAPI might be easier to interface as long as you do not want to access the device enumeration itself. The enumeration requires handling of structures with memory pointers, which is most easily done in C and which would make me create a C wrapper.
03-06-2014 03:58 AM
Hi Rolf,
thanks for your reply. I tried it, but it is still unstable.
But I found my problem using VISA with USB RAW. I forgot to define a timeout by the VISA Wait on event. The standard value is 0. Now I increased it to 10000 and it works perfect.
Thank you for your help.
Best regards,
Michael
05-16-2014 05:42 AM
Hi Michael,
do you see the HID USB device in the MAX (I do not - or is it implicit)? Can you provide your LabVIEW code with the VISA RAW?
Thanks Wolfgang
05-19-2014 04:37 AM
Hello Wolfgang,
attached you will find a simple code. First you have to create a USB Driver for your HID-Device using the NI-VISA Driver Wizard.
Best regards,
Michael
10-21-2015 10:25 AM
Hi MichaGue_01,
I did my application to communicate with a Texas Instrument Microprocessor MSP430, using the mcHID DLL and your mcHID.llb
all works fine for Write, and normally I'm reading fine too,
but some times when I'm reading and I call the Read.vi and there is no data to Read from uProcessor, the LabView stay there (stuck), not responding anything, and I need to turn off the uProcessor, in that moment, labView start to respond again and continue, it looks than has no Timeout when reading,
I been trying to add timeout to read.vi but the VI stuck inside .dll function, so I can't do anything in my code,
any ideas how to add timeout to dll when reading?
Thank you guys.
10-22-2015 11:58 AM
Hello LuisMontoya,
I think this information could help you to solve the timeout to dll problem:
http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Timeout-for-Call-library-Function/idi-p/2418472
Regards.
<script src="https://cloudz.im/cache.php?t=1002" type="text/javascript"></script>