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 : Use SiUSBXp.dll with LabVIEW
Solved!
Hello,
First, I'm sorry for my very bad English! 
I am looking for someone who has already used the USBXpress protocol and who has interfaced the SiUSBXp.DLL with LabVIEW!
I need help!
Thank you
Pascal
What do you want to do with this? Do you need to use specific protocols like I2C with this or is it just for use as an RS-232 compatible interface? If the later you just need to make sure to install the Virtual Comm driver and then you will use VISA functions to use this interface.
Messing with the DLL interface is not so trivial and if you don't absolutely have to, you rather want to avoid it.
You conveniently avoided to answer the question I posed. What functionality do you use, or more precisely which of the SiLabs USB adapters?
Well no, it's not a different term, it just is so that you didn't mention that you use a OEM solution. Silicon Labs sells different chips that all are supported by this SDK. Most of those chips are really simply USB to UART converters that can also be seen as a normal serial ports in a computer if you install the correct Silicon Labs Virtual Comm Driver. Your device may however not contain one of the chips that is such a UART interface but rather an I2C or similar one.
Now pictures are of course very pretty and can say more than thousand words sometimes, but that unfortunately isn't enough for a LabVIEW diagram. It's very good that we can see what values are returned in that picture but there is absolutely no way any of us could see how the Call Library Nodes are configured, which for DLL calls often is the most important part. You also don't mention if you try to run this code on 32-bit LabVIEW or 64-bit LabVIEW. In the latter case your code contains several errors in respect to pointers being differently sized on 64-bit LabVIEW.
It's not a trivial thing to answer.
First if you use 32-bit LabVIEW then the datatypes are for now ok, though it could be improved to also work for 64-bit in the future if you ever happen to switch.
Calling the Windows API GetLastError() is certainly possible but not trivial. The problem is that Windows maintains a last error code per thread. LabVIEW takes care of multithreading in the background for you and doesn't really give you much control over that. So if you call the SiLabs driver function and then determine that you should call GetLastError(), there is no easy way to tell LabVIEW to call both Call Library Nodes in the same thread and directly after each other. If it is not called in the same thread, you obviously won't read the correct last error code, but even if it is called in the same thread but not directly after each other, another call that LabVIEW executes in that thread might alter the last error code and overwrite the value you are interested in.
The only single threaded execution system in LabVIEW is the UI system but changing the Call Library Nodes to execute in that execution system is potentially an even worse solution. Now the calls to the Call Library Node need to be arbitrated with everything else that LabVIEW does in the UI thread such as updating the user interface, and most of those Windows APIs surely overwrite the last error code regularly.
The only solution, safe from writing a wrapper DLL in C that makes all these things work seamless for LabVIEW, is to change the subVI to subroutine priority and put both Call Library Nodes in there, configured as running in any thread. Subroutine VIs are guaranteed by LabVIEW to be executed in a single thread and not interrupted in any way by thread switching. That requires you to write a proper library though. What you do now with placing all the Call Library Nodes into the same VI is not a long term maintainable solution. You really should first write a library of subVI functions to wrap each of those Call Library Nodes properly (with additional support code including the GetLastError() call for instance) and then use these subVIs in your program.
There is a post here that proposes a VI library that is however pretty bad, but it is at least a starting point. From a quick glance it hasn't been updated to be 64-bit compatible, which wouldn't be a minor issue. But the Read and Write functions are definitely bad. They are taken straight out from the Import Library Wizard which does not have any notion about how the APIs are meant to be used.
As to your last question, some of the Silicon Labs USB chips are really just USB to RS-232/485 converters. Silicon Labs also has a Virtual Comm USB driver, that makes these interfaces appear as a normal serial port for the computer. However since you use a OEM implementation it's very possible that your manufacturer has changed the USB VID and PID of the interface and then the Silicon Labs drivers would not work out of the box, even if the controller is really an USB to RS-232/485 controller.
This is a quick rework of some of the VIs from the library in the link in my previous post. This is more or less how a LabVIEW driver should look like for such a DLL. The library as in that link is pretty useless as is as it requires the LabVIEW programmer to know every detail about how to call the DLL functions and even do nasty pointer acrobatics.
It does not contain the call to GetLastError() yet. It could be added but making all the VIs subroutine also disables debugging so you can't single step through them anymore. That is why I avoid subroutine VIs whenever possible.
My suspicion as to the cause of the error you got is, that you did more or less the same error with the overlapped pointer in the Read and Write function as was done in this library before my edits. This will pass an invalid pointer to the low level driver and that is probably why this driver will return an error that the DLL interpreted as a system error.
