DIAdem

cancel
Showing results for 
Search instead for 
Did you mean: 

Help integrating .NET dll through LabView calls

I'll preface this with saying this is my first time trying to call Labview VI's from DIAdem, and more specifically, ones that are calling a DLL.

 

Ultimately, I will be using a much more complex DLL, but just to get my feet wet, I created a very simple calculator DLL.

 

I have a .dll that was created with C# targeting the .NET Framework 4.7 (I also tried building targeting .NET 4). I've created a Labview project containing this DLL and two simple VI's. One VI is some simple mathmatical operations to test my DIAdem calls to Labview with a simple VI and the other contains code to call the DLL. The VI calling the DLL uses the Constructor Node to create a reference to the DLL and then an Invoke Node to call the methods in the DLL, see image below.

Interface_Screenshot.png

 

In LabView, the "Interface.vi" VI runs just fine and calls the DLL as expected.

 

Then I tried running the same VI by calling it through DIAdem and I get the following error:

DIAdemError.png

 

Please see the attached script (TestInterface.VBS) that I am using to load the VI. Basically, I'm initiallizing the LVRuntime and then using LVRuntime.LoadVI. I read in the help, that to use a VI created in LabView with the Runtime environment, you need to build a Source Distribution, so I built one that includes the DLL and both VI's in the Labview project. However, when I try to run the script, the same error occurs. Then I tried loading the other VI that does not call a DLL ("SimpleTest.vi") and the script runs as expected for that VI (regardless if I'm using the raw VI or the source distribution).

 

Additionally, I found a DIAdem example that calls a VI to integrate an external DLL ("Integrating an External DLL to Calculate Prime Numbers"). I called my script to load the VI from that example ("LVR_Calc_Primes.vi") and my script works just fine. I'm assuming that since that VI is using a "Call Library Function Node" that the DLL was compiled from C++ and not C#.

 

The other difference I noticed is that the example VI and DLL are located in the DIAdem program directory, while my calculator VI and DLL are located on a network drive. 

 

So I'm not sure if I'm doing something wrong, or if there is a different method of calling .NET dll's from DIAdem. I've attached the C# source code, LabView project and VI's, DLL and DIAdem script. Any help or tips would be more than welcomed! Thanks.

0 Kudos
Message 1 of 15
(5,101 Views)

Hi there. I see you already got the Source Distribution part, but I wonder if maybe you forgot some other detail. Have you seen this page?

0 Kudos
Message 2 of 15
(5,030 Views)

Hi meatballosaurus,

 

Can you turn that source distribution into a LabVIEW .exe that runs correctly and calls your .NET code?  It would be nice to take the DIAdem angle out of this and just verify that the VI-calling-.NET is working as an executable.  I think in any event we're going to have to lean on LabVIEW support to make progress with this.  The DIAdem R&D team is not aware of any reason why the LVRuntime would not work with a VI that calls .NET.

 

Brad Turpin

DIAdem Product Support Engineer

National Instruments

0 Kudos
Message 3 of 15
(5,023 Views)

brandonj - I had not seen that page, but I had already done most of the things specified there. I did follow it step for step and had the same problem. Also, the "SimpleTest.vi" in that same project/distribution works just fine, so I believe I built it correctly.

 

Brad - I was able to build the LabView project as a standalone .exe and it runs just fine by itself. I've attached a .zip that contains the build folder that LabView created including the executable and the .dll file in the data folder. Let me know if this doesn't work. (I'm not sure if it matters, but I built it with Labview 2017).

 

One thing that I noticed was that while building the .exe, it didn't allow me to include the .dll as a source file, but instead copied it to the supporting "data" folder. I tried rebuilding the source distribution using this same method, but this didn't help and DIAdem still has the same error.

 

Is there a way to call the Labview executable from DIAdem? Or can I call the .NET assembly directly from DIAdem? I don't necessarily need to use Labview, I just thought it was going to be the most straight forward way to do this. Otherwise, what's the best way to get the Labview support team invovled?

 

Thanks

0 Kudos
Message 4 of 15
(5,019 Views)

Hi meatballosaurus,

 

There is a DIAdem command "ExtProgram" you can use to call a DOS executable, but I actually prefer the Windows Shell object, which you can use with VBScript like this:

Set WSH = CreateObject("WScript.Shell")
Call WSH.Run("""" & DosFilePath & """", 0, FALSE)

One advantage of the Windows Shell approach is that you can specify whether you want to call the DOS executable synchronously or asynchronously.

 

In order to get assistance from the LabVIEW crew we'd need to demonstrate a problem without DIAdem.  It sounds like that's not an option.

 

Brad Turpin

DIAdem Product Support Engineer

National Instruments

0 Kudos
Message 5 of 15
(4,963 Views)

Brad,

 

I used the Windows Shell object as you suggested and I was able to start the executable I attached in the last post from DIAdem, so I guess that proves that it works. DIAdem opens the executable VI and then finishes the script. I'm then able to do whatever with the executable, but it seems it now operates independent of DIAdem.

At the end of the day, what I want to be able to do is pass some data to the VI, have it do some calculations through the .NET assembly, and then pass back the results to DIAdem (or bypass LabView all together and just call the .NET assembly straight from DIAdem).

 

Any thoughts on where to go from here?

0 Kudos
Message 6 of 15
(4,946 Views)

Brad,

 

I was doing a little more digging and was wondering if it might have to do with the Labview Runtime Engine not being able to run some of the controls in the VI that calls the .NET assembly.

 

I found this page: http://zone.ni.com/reference/en-XX/help/371361P-01/lvprop/propmethnosuprtrte/. If you scroll down to the "Individual VI Server Properties and Methods Not Supported" section, it specifies that the "Invoke Nodes []" under the "Control Properties" is not supported. I'm not sure if this is the same as the "Invoke Node (.NET)" that I'm using to call the assembly methods. The thing I don't understand though is why the executable works, doesn't that use the Runtime Engine as well? Perhaps this is something we should ask the LabView support?

0 Kudos
Message 7 of 15
(4,933 Views)

I noticed that I wasn't able to run your .exe with only the regular 32 bit LabVIEW runtime engine. I had to install the 64 bit 2017 runtime engine. I wonder if this is a bitness issue (DIAdem 32 bit trying to run/open a 64 bit program)? I support LabVIEW and can definitely continue to support through this forum. Alternatively you could create a service request at ni.com/support.

0 Kudos
Message 8 of 15
(4,900 Views)

brandonj, 

 

That's a good thought but I don't think it is the issue. I have both 2017 32 and 64 bit versions of the runtime engine installed and was using 2017 64 bit version of DIAdem. That brings up a good point though, if the .exe can run the .NET assembly calls with the runtime engine, then I don't see why DIAdem using the runtime engine can't load the source distribution with the .NET Invoke. Am I thinking about that right?

 

If we can't run this out in the next week or so, I'll probably submit a service request, thanks for the suggestion.

0 Kudos
Message 9 of 15
(4,886 Views)

I tried a bunch of different source distribution builds with your code (32 bit and 64 bit LabVIEW and DIAdem) and see the same thing you're seeing (works fine as a standalone VI or exe, but not when called in DIAdem). I also noticed the same occurs even with a shipping LabVIEW example of VIs using .NET (I tried "Task Monitor Using .Net objects" example). Using "Diagram Disable" around the .NET portions and rebuilding allows it to run correctly suspect this is an issue with DIAdem calling VIs with .NET.

0 Kudos
Message 10 of 15
(4,859 Views)