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.
In using your mcHID.dll. In my application it's super unstable when reading. The othe funtions works pretty well. Did you maked more stable?
at the end I stopped using mcHID.dll and I solved my problem with VISA and USB RAW. If you look at my posting 18, you will find a simple code for USB RAW and VISA.
Thank you for replying. I already tried USB raw. I created a drive with VISA wizard, but couldn't import in my applications. It works very well in my PC, but I couldn't make it work another Pc's. I read, in other chat, that USB raw is not a good choice, so I'm trying to use .dll. I truly don't know what is the best choice.
This is what you are looking for:
contains some VIs to access your HID device. No extra DLLs are needed.
The HID Version is nice and it finds my device. But how is the data transport done? The llb does not contain routines like read and write.
Probably it is HidP_GetData and HidP_SetData but I do not know the parameters.
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.
Thanks for pointing me in this direction.
Unfortunately, it did not work with my device. Labview waited .... till I stopped it from windows (:-(
I am not very sure about the USB device. It is a Attiny85 with a simple program writing data to the USB port.
I got some of these devices and thought they would work like every other Arduino, but the USB interface is different.
I was able to use the examples with HID devices and now I can use the Joystick emulation to transfer data from the Attiny to Labview (keyboard and mouse work too, but interfere with other input), but this interface has a lot of restrictions and I would be glad to have a "normal" USB connection.
Before Windows 10 Labview was able to communicate with Raw USB data, but now the device driver has to have a signature which makes this much more complicated.
Probably I should open a new topic "Attiny to Labview via USB".