From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
USBxpress.dll and Silicon Labs library 2012 in. LabVIEW
Solved!
The problem is that you (or whoever did this) created the VIs with the Import Library Wizard from the C header file (and several other problems in your program).
This Wizard can not know that a pointer to an int32 can also indicate a pointer to an array of int32. The C syntax in the header file is not sufficient to specify such "minor" details and the Wizard has to go by what the syntax can mean.
Your wrapper VIs need to be all reviewed and modified to do what the DLL function wants not what the header file (supposedly) declares.
Also you Open the device and Close it immediately without waiting with that after the Write and Read function have completed. As is, the device handle opened by the Open function has already been closed and invalidated by the time your Write function gets to execute.
If you don't have some detailed C programming knowledge it is basically asking for trouble to use the Call Library Node in LabVIEW. The Wizard only can generate VI templates based on the header declaration but this won't be correct ever if the parameters are something else than scalar values since the C syntax is simply not able to declare all aspects of buffer handling for array and string parameters. A lot of that has to be derived from the Programming Manual description, example source code and/or assumptions and trial and error.
Well, that library is pretty much simply the output from the Import Library Wizard and it seems the guy did go through the trouble of adding the comments from the Programmer Manual to the VI controls. Quite laudable effort but unfortunately pretty useless if the Import Library Wizard generated code is simply left as generated.
First problem: The HANDLE is a real handle meaning a pointer sized variable, so it should be configured as pointer sized variable in the Call Library Node in all VIs and the control in the front panels should be changed to a 64-bit integer.
Second: The Read and Write VIs are terribly inadequate. The buffer control in the front panel should be simply am array of bytes and it's size should be passed to the Bytes to Write parameter. Similar for the Read function. And any other function that might be intended to read or write some buffer data through the DLL should receive a similar workout.
Third: it is equally criminal to even pass out the overlapped parameter. If you wire anything else but a 0 to this control the function will think it is a pointer to an overlapped data structure for asynchronous function calls and BOOOM, another crash is waiting!
Trying to pass your data to the current buffer parameter has several problems. First the data is not sent at all like that, instead the DLL function tries to interprete your data as a pointer to some memory buffer. It only doesn't crash immediately since you leave the Bytes To Write value at 0, so the function bails out with a parameter error before even trying to reference that invlaid pointer as it makes no sense to call it with an empty buffer.
Basically whoever did create that VI library did not know even remotely enough to make it really useful and should be punished!
Check the link from your post. I attached an updated archive with updated VIs that should work a lot better. I don't have any hardware to test this so it is still a fully unverified VI library but at least the Read and Write functions are now according to what the documentation would indicated. Before they were simply totally wrong.
