From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Need Example Code to Interface with a USB HID compliant Device
It's an idea exchange suggestion from an user and LabVIEW R&D has declined that option for various reasons. The main reason is that LabVIEW has absolutely no way of aborting the thread safely in which it executed the Call Library Node call. The DLL call could be in some intermediate wait state, for instance waiting for an event from a call to a kernel driver invocation and terminating that thread in mid air would be about as similar as stopping your car by crashing it in a wall. Very effective but not safe at all!
Your DLL specifically has to provide an interface to abort a function call, such as a second function call that you could invoke from another place in your LabVIEW program if you decide that it was waiting long enough. If it doesn't then there is simply no safe way of aborting it without requiring a complete restart of the entire application.
Only the DLL developer self can decide when it is safe to cancel a specific operation, nobody else.
It actually does: ReadFile.vi is the function to use to read data from the device. It misses an according WriteFile.vi function though.
With a tiny little magic it could be even done so that one could use the LabVIEW Read and Write Binary File functions but I can't currently test that approach.
As to the comment in the HID_CreateFile.vi about the use of GetLastError() not working.
No LabVIEW does not clear the last error intentionally. But this value is maintained by Windows on a per thread base. Both Call Library Nodes are configured to be executed in the UI thread but this thread is shared with the LabVIEW user interface handling which does call all kind of Windows APIs that do use this last error too. The chance that there is no other code execution in the UI thread between the call to the CreateFile() function and the GetLastError() function is almost infinitesimal small. So the last error value has been almost always overwritten by a call to other Windows APIs at the time GetLastError() is called.
Changing both Call Library Nodes to run in any thread doesn't guarantee proper operation either. The two Call Library Nodes easily can end up being called from different threads belonging to the thread pool for the execution class the calling VI is executing in.
The only solution in LabVIEW land that is guaranteed to work is to make the VI a subroutine and configure both Call Library Nodes to execute in any thread. Subroutine VIs are guaranteed to be executed completely in the same thread. This does require that the DLL functions being called are thread safe of course, in order to configure the Call Library Nodes to run in any thread, but for most Win APIs that is generally a given.
