Issues with LabVIEW calling .NET DLLs

[Hang007]

Hi everybody,

My project:

In the lab, we have a LabVIEW system to control motorized stages and other hardware. Now we want to use a sub module to control a spectrometer with its instrument API.dll which is based on .NET framework. So that we can incorporate it into our system. 

Where I am:

1. C# codes with API.dll as reference work well on the spectrometer. 

2. I make application .dll using Visual Studio. Build C# solution into class library targeting x86 CPU. So both API.dll and application .dll are 32 bit. 

3. I practice LabVIEW .NET calling .dll embeded with third .dll for mathematical equations or System.IO to play around window files. They all work.

4. I only have poor understanding of .NET and COM. 

My issue:

When I use 2016 32 bit LabVIEW to call the application .dll, vi went through without error message, but there's no response from the machine. If I hard code a wrong string in C# codes, then when LabVIEW calling this .dll, the string in C# codes, "throw new Exception(" ")", will pop up in my VI. It looks the C# program was executed to some degree. In the mean time, another lab mate is trying to use LabVIEW directly access API .dll using ActiveX interface.

My questions:

For this project, is LabVIEW .NET interface the right way to go? I am really not sure if there's fundamental problem for such a practice. And can I get to know how the codes in my application .dll are executed in this combination?

Since the API.dll won't work without the hardware and license, I don't attach anything here. If VIs and codes are helpful for troubleshooting, please let me know. Thanks!

[rolfk]

A long and pretty detailed explanation but to be honest I didn't understand most of it. What is this application.dll?

Why did you do this application.dll to call your other DLL and then try to call this application.dll from LabVIEW?

What prevented you from calling the actual DLL directly from LabVIEW?

What wrong string in the DLL Why does it throw an error? What pops up? A LabVIEW dialog? A .Net exception dialog? A magic fairy?

As to if calling .Net DLLs is the right thing to do in LabVIEW: If all you have from the manufacturer but this .Net DLL interface it's the only thing you can do safe from reverse engineering the communication interface to your hardware, so talking about if it is the right thing to do is pretty moot.

And if .Net is working in LabVIEW, I think you can answer that question yourself as you have other .Net interfaces that you use which seem to work just fine.

It seems your problems are with this application.dll that you created and we really can't help you with that much.

[Konan__]

Listen to me bro,

dont use Labview.

Use Visual Studio, create a new WinForm project.

Add you dll references to the project.

Place a button on the GUI, double click it, and write you code in the event handler.

Once everything works with third party dll, spectrometer, etc.... create a new project (class library) that outputs a DLL. Just create a Wrapper class that does the same.

Build.

Now you take all your DLL (build, and third party), and copy to a Labview folder, and you can start using it, with constructor node, property node and invoke node.

Just do simple thinks (public property, public methods) and you are good to go.

Anyway, you really dont need Labview if you just have to wrap code that is already in C#/.net.

[Hang007]

Hello Rolf, thanks for your reply! The third party DLL is like a library. I wrote application C# codes to create a class instance and call some methods from the library to make spectrometer do a specific job, e.g. acquire data from 1 min. In order to incorporate it to our LabVIEW system, I built them into DLL, hoping that them can be interfaced with LabVIEW.

In the case you mentioned, we basically use a string of instrument name to connect the hardware. If I hard code the wrong name, the same error message is thrown in C# console application console window, and VI dialog which calls C# DLL. 

My experienced colleague was trying to use LabVIEW directly call third party DLL, however, he couldn't get this solution work. But I don't know why he failed in that way, as I sadly don't solid basic knowledge for this topic, and couldn't find good learning materials online.

[Hang007]

Thanks so much for your reply! I think I did similar thing as you suggested.

In works I mentioned in the post, I used Visual Studio to make console project: 1. 3rd party DLL as reference, 2. main codes in one class. Some class members are using(){call methods from 3rd party DLL}, 3. another class (I guess the wrapper class you mentioned) has public class and class member to create the class instance. 

The console project works fine, I see response from the spectrometer. But if I build it into DLL instead,  and use constructor node and invoke node to call the public member in the last class, I see no response from the spectrometer, although there's no error message. 

Could you give more hints with these updated info? Thanks a lot!

[srikrishnaNF]

Hi Hang007,

Which class you used to build the dll?If it is class as in step#3,then that is the reason for not working as intended in LabVIEW environment.

Because you are trying to access that .net dll which in turn trying to refer the class (step#2) which actually accessing the 3rd party dll.There are multiple layers involved before reaching the 3rd party dll.

Please create a class and code the methods to actually refer the 3rd party dll .Then build that class to a dll  and then call into LabVIEW using .net constructor node.

[Hang007]

Hello Srikrishna, thanks so much for your reply. Yes, the #3 class is used to build the dll, and called in the final VI. Maybe too much layering is the trouble maker in LabVIEW environment, I will definitely try your suggestions!