LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

USBXpress : Use SiUSBXp.dll with LabVIEW

Solved!
Go to solution
Highlighted

Hello,

First, I'm sorry for my very bad English! Smiley Sad

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

0 Kudos
Message 1 of 11
(1,213 Views)

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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 2 of 11
(1,182 Views)

Hello Rolf,

Thanks for your reply.

My interface does not use any virtual COM ports but communicates directly via USB using the USBXpress API. It's my problem....

That's why I'm looking for someone who worked with USBXpress.

0 Kudos
Message 3 of 11
(1,173 Views)

You conveniently avoided to answer the question I posed. What functionality do you use, or more precisely which of the SiLabs USB adapters?

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 4 of 11
(1,168 Views)
Hello Rolf.
I do not know the term "USB adapters". The term must be different between English and French ...:smileyfrustrated:
My device is a Datalogger from Lascar Electronics, the EL-USB-4, which uses the USBXpress development solution from Silicon Laboratories. It was the company Lascar that gave me this information.
Next to my message is the diagram of my VI. In red, that's what I put in the input and green, the answer obtained.
We see that the problem comes from SI_write which sends an error ... The string constant is correct.
The first 2 calls to the DLL are correct (no errors : SI_Status = 0). I do not understand the SI_write error ...
Best regards
Pascal
0 Kudos
Message 5 of 11
(1,155 Views)

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.

 

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 6 of 11
(1,152 Views)

Hello Rolfk,

Thank you for you precious help !

I have 2 questions to ask you if you allow me:

1) My version of LabVIEW is a 32-bit version. The output error of the SI_Write function (in my case 0x0C) is an SI_SYSTEM_ERROR CODE error from the Silicon Labs document titled "USBXpress Programmer's Guide". The documentation says, about this error, "Call GetLastError (Win32 Base) to retrieve Windows System Error Code. The error codes are defined on MSDN".

I think that knowing the type of error I could perhaps more easily correct this error. Is it possible to call the GetLastError function with LabVIEW, but if it's possible, how?

2) In your first post you talked about using the NI VISA functions that I know because I used these functions a lot with RS-232 devices (easier to manage with LabVIEW). Is this possible in my case with my USB device? If so, is it easy to do?

 

I am a teacher and I have to do a project with the students using as an application, LabVIEW. By cons I know almost nothing on the USB hardware or the USB protocol. The goal is to retrieve the data provided by the device (in ASCII) and analyze it using LabVIEW ...

Thank you again for your help !

Best Regards

Pascal

0 Kudos
Message 7 of 11
(1,142 Views)

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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 8 of 11
(1,136 Views)

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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 9 of 11
(1,131 Views)

Hello Rolf,

It works !! Enjoy !! You are a great computer god !!

No more errors in communication and I receive many bytes from the device!

In fact, I had found the VI library! I am very strongly inspired to build my VI (see my picture diagram.jpg).

On the other hand, my mistake is in the nature and structure of the variables! I put you in picture what I programmed at the call of the DLL.

Without you I would never have found what to do. Thank you very much !! I'll be able to keep going in the dialogue between the USB device and LabVIEW !!

I will try to understand what you did to advance in my knowledge of DLLs !!!

Could I use your under Vis (SiUSBXp Driver.zip 114 KB) to communicate them to my students for their project next September?

I will indicate in my subject of project, if I arrive at the end of the project, that all this is thanks to you!

One last question…. What is your nationality and what do you do as a job?

I will keep you informed of the progress of the project. Do you have a personal email address or I will in the future interact with you through the forum Ni Community ?

Many thanks for your help !

Best Regards

Pascal

0 Kudos
Message 10 of 11
(1,118 Views)