dll multiple functions that share common variables.

[vakost]

Hello.

I want to build a dll with many functions. The functions are going to be open, close, read, write and many other operations with many instruments.

The different functions are different subvi's inside the dll.

My question is how to share some variables between the different subvis.

For example, the "open" vi is going to initiate communication with several instruments, how is the VISA resource name information going to be shared between the other vi's?

The obvious answer to me is the use of global variables. The reason I am asking is to verify that. For example, is there another more efficient way of handling this, especially create for this use?

Also, an example would be quite helpful if it is not too much trouble.

Thanks a lot.

Vasileios.

[rolfk]

A much better aproach than sharing some information implicitedly between functions is to store them in some structure that is created on open() and return the pointer to that structure from the function. Then pass this pointer to each function. The close() function destroys that structure.

Implicit sharing between functions has many drawbacks including to limit your library to never ever being able to work on more than one resource in parallel. Also globals between functions are always suspect and can easily create race conditions. You'll have to do some verification anyhow in each function that those globals have been properly initilialized so why not do that on the information in the passed in pointer instead?

If you really want to go the route of implicite data in a LabVIEW created DLL you will have to use LabVIEW globals.

[vakost]

Hello rolfk and thanks for the quick reply.

Can you point to an example or give an example of what you suggested?

How can I share the pointer of a structure between vi's? Using again a global variable?

Isn't this going to introduce the same problems?

Thanks!

[syrpimp]

hello  vakost,

don't make it complicated. why not try to create a sub vi for every operation. and place them in one/single  VI,  I think this is the easy way to do to solve your problem.

in example below for NI USB 8451, inside of that single VI includes sub VI for some function to command NI USB USB 8451, you can Pull what function are you going to use. and its working for me.

[rolfk]

Well, first question is maybe why do you want to create a DLL from LabVIEW code? Creating a DLL to call the code from LabVIEW is a very inefficient way.

What is this DLL supposed to really access? If it is VISA, why not pass the VISA session between functions?

[vakost]

Helo syrpimp,

I don't understand this solution.

How is the input of each subvi going to be determined by my caller program? The top hierarchy vi you gave me is not actually running, is it?

[vakost]

rolfk,

I have the scheduler with the Graphic User Interface ready, it is a program we use in our company for many years.

This program calls some functions from the dll's we are working with (each unit has its own dll).

The dll I am going to write is going to be used in a cRIO, so it is going to use FPGA LabVIEW.

Is this supported from CVI?

Can you suggest a better way?

[syrpimp]

that was a single VI or function call that does multiple operations based on a parameter you pass to it.

You can create a single dll with mutiple functions. Each function is a separate VI. Each VI or function call will have it's own set of parameters.

[vakost]

syrpimp,

I understand that but I have the following question:

1. I call the open function. After some other operations,

2. I call the read function. How is the read vi going to read the VISA resource name of the instrument?

[rolfk]

Huuuhh, CVI?  on cRIO?

Where did that suddenly come into play?

Is this DLL for the cRIO part? Are you going to write the rest of the cRIO application in CVI?

There is a C API for LabWindows CVI. It allows you to access cRIO from a Windows machine but I'm not aware that it allows you to deploy executables directly to the cRIO. Personally I would write the entire cRIO application in LabVIEW and then write an interface DLL on the host that communicates with the cRIO application through TCP/IP.