dll multiple functions that share common variables.

[syrpimp]

I've never tried this. What I normally do is have the subVI/function call return a parameter I need to pass to another subVI/function call. For example, if I have an open function in which I need to pass a file name, I have it return the file name so that I can wire this parameter to the write function. This enables data flow which is very nice to have.

[vakost]

rolfk,

No no, I was just answering your question. You asked me why do I want to write dll's in LabVIEW.

So, this is exactly what I want to do (I hope it will give you a better overview):

1. The program that my company uses is written in CVI (the scheduler and the GUI I was talking about). It calls some functions from a dll.

2. I am going to write that dll. It will run in a cRIO. It will write some vi's that talk to the FPGA of the cRIO (obviously written in FPGA LabVIEW) and some vi's that are communicating with the FPGA vi's. The latter vi's are also going to form the dll's functions that are speaking to GUI+Scheduler program I mentioned in (1).

I hope that this is clear enough!

Vasileios.

[rolfk]

Well, you can NOT call a DLL on another system (here your cRIO) from your host application (CVI on a Windows system). So you should anyhow rethink your design. What you will have to write is a DLL (in CVI or whatever that runs on the same system as your CVI application) and that somehow communicates with the application that runs on your cRIO (and that is preferably fully and entirely developed in LabVIEW). 

[vakost]

rolfk,

The cRIO I am using is the 9081 with an embedded windows configuration (which I forgot to mention....). It has a CPU.

In this CPU, I will run the CVI (GUI+Scheduler).

In the same cRIO, there is going to be a DLL.

This DLL is going to be a part of a project that will have some vi's written in LabVIEW FPGA and some vi's written in LabVIEW.

These vi's will communicate with each other.

The vi's that are written in LabVIEW will provide the DLL functions that will speak with the CVI (GUI+Scheduler).

Is this doable?

I understand that I am terrible at explaining things.

I apologize.

Vasileios.

[rolfk · Accepted solution]

So this DLL is going to be treated as a plugin by your CVI applicatio?

It sounds then that your DLL has to have a very specific interface (predefined names and parameters) that you can't change.

In that case it also depends a bit what parameters this interface requires. Not every possible parameter datatype is (easily) supportable in LabVIEW. That would be the first thing to check. As long as it uses only scalars (single numerics), 1D arrays of scalars, structures containing scalars, and C strings its all doable. multi dimensional arrays or structures containing array or string pointers is going to be a major pain to support in LabVIEW.

If that is all clear and the functions do not allow for some form of parameter to identify a resource, you will have to store any information that needs to be shared between function calls either in a global or an intelligent global variable (LV2 style global: basically a subVI with uninitialized shift register).