LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the best solution to execute VIs from C# program

Hello,

how can i create an interface from a my custom C# operatorinterface to execute a VI using the Labview Runtime?

On the UI is an button which should when pressede execute a VI and pass parameters to the VI and also some back.

Is there an example somewhere?

Thanks

BR

0 Kudos
Message 1 of 8
(794 Views)

Build your VI as a dll.  That's all I can think of.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 8
(713 Views)

You can check out "Calling LabVIEW VIs from Other Programming Languages", which includes 2 methods (DLL as mentioned, or ActiveX calls) and has some sample code and examples at the bottom of the page.

0 Kudos
Message 3 of 8
(695 Views)

Thanks for the link. The execution of VIs is running now by building them as DLL.

The question is now: How can in now pass data into the running DLL function? (and out)?

What kind of "handle" can i pass when calling the vi-dll-function wo use it later wo pass data?

...

MyDLL.ExecuteVI(handle XYZ); //running parallel

...

XYZ = "newdata";

...

 

Thanks

0 Kudos
Message 4 of 8
(643 Views)

Hello,

 

Maybe this forum can be helpful for you

 

https://forums.ni.com/t5/LabVIEW/Read-data-from-dll/m-p/3802759#M1073368

__________________________________________
The best way to thank, is to give KUDOS
0 Kudos
Message 5 of 8
(499 Views)

@OnlyOne wrote:

Thanks for the link. The execution of VIs is running now by building them as DLL.

The question is now: How can in now pass data into the running DLL function? (and out)?

What kind of "handle" can i pass when calling the vi-dll-function wo use it later wo pass data?

...

MyDLL.ExecuteVI(handle XYZ); //running parallel

...

XYZ = "newdata";

...


This is not a simple topic. The main principle is that DLL interfaces must adhere to C programming standards and that means they are very loosely defined, much different to the C# managed environment or the LabVIEW internal management model.

 

So when you create your DLL you have basically two choices:

 

1) define variable sized parameters such as strings and arrays as native LabVIEW handles.

 

2) use standard C pointers

 

Each of these methods has advantages and disadvantages.

 

For 1) you can not allocate, resize and deallocate those handles with your standard memory management calls. Not only are LabVIEW handles special datatypes that use internally additional information for LabVIEW to manage them, but you also have the problem that malloc() in your calling process may (almost certainly) not be the same than malloc() that the DLL uses. This is because of different C runtime version linkage of your caller and the called DLL.

For this reason the LabVIEW DLL builder will add additional function exports to the DLL that you NEED to use to allocate, resize and deallocate those handles. This makes sure that the same C runtime memory manager functions are always called on a specific handle. The DLL specifically reserves the right to use these functions to manage any handles passed into the DLL(and returned back from it).

 

For 2) it means that the caller has to provide all and every memory buffer for both input (logically) but also any output parameter and that especially for output parameters you have to make sure to preallocate a large enough buffer so that the function will not overrun it when trying to fill in its data. 

Rolf Kalbermatter
Averna BV
0 Kudos
Message 6 of 8
(478 Views)

I can Think of some alternative solutions.

DLL

ActiveX

.NET assembly

TCP/IP (start a LV program and communicate with it through TCP/IP) (This also includes RabbitMQ and similar)

Command line (call a LV program with some in parameter, maybe it'll result in a file to read)

Web service (communicate through the web)

 

I bet there's a couple more. 🙂

They all have some pro's and con's.

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
Message 7 of 8
(472 Views)

@Yamaeda wrote:

TCP/IP (start a LV program and communicate with it through TCP/IP) (This also includes RabbitMQ and similar)


I'd add:

+ start a LV program and communicate with it through named queues

 

Those are Windows named queues, never name LabVIEW queues!

0 Kudos
Message 8 of 8
(439 Views)