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

[OnlyOne]

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

[billko]

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

[Kyle97330]

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.

[OnlyOne]

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

[VA.KI]

Hello,

Maybe this forum can be helpful for you

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

[rolfk]

---

@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. 

[Yamaeda]

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.

[wiebe@CARYA]

---

@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!