LabVIEW
How to call USB Reset Utility for Silicon Labs .dll
Solved!
Excuse me, I tried to use the following command, why did it fail?
GetUSBDeviceSN(DWORD dwDeviceNum, const char ** psSerialNum);
@yusung wrote:
Excuse me, I tried to use the following command, why did it fail?
GetUSBDeviceSN(DWORD dwDeviceNum, const char ** psSerialNum);
Because you try to call a C function without fully understanding C programming!
The Call Library Node gives you the ability to call such functions. It doesn't and can't make it as fool proof as calling LabVIEW functions.
Following errors are present in your code:
1) You tell LabVIEW that it is safe to pass that parameter without reevaluating it after the call because the function won't modify it (by checking the constant checkmark).
2) You pass in a fixed value 1 to the dwDeviceNum parameter. The description explicitly says that to address the first device you would have to pass in 0. Your device number 1 is only valid if you happen to have at least two debugger devices connected to your computer.
3) You assume wrongly that a LabVIEW string is the same as a C string pointer. It absolutely isn't! Therefore you can't just pass in an array of LabVIEW strings and magically hope that the function somehow will return some information. If you hadn't wired 1 to the dwDeviceNum, resulting in an invalid device index, the DLL would have overwritten the LabVIEW string handle entry by its own string pointer and on return LabVIEW would have tried to interpret that pointer as a string handle and crashed.
OMG! During study,I've read the third point several times, but I don't understand it very well.
I used the method you gave to successfully get what I want, but there is still an error out, is this normal?
No it isn't, but since you obviously didn't use the VI I attached (mine has a dwDeviceNum input), and failed to attach yours, I can't know what might be the problem.
Which function gives you that error?
It's hard to guess and I can't run the VIs on my computer as I do not have that hardware available. From a Quick glance the VIs seem to be configured properly. Sorry about the calling convention mistake for the LabVIEW LStrPrintf() call. It was a quick and dirty copy paste mistake.
My guess is, that the DLL might try to load the (or another) secondary DLL to implement the actual connection for the USB type and unless it does some rather unusual path calculations of its own to build the correct path to the secondary DLL relative to its own location, it must fail since Windows will not find that DLL in the same folder as the main DLL that you load with LabVIEW.
