Problems using LabVIEW-built dlls in LabVIEW

[reke]

I have built a set of LabVIEW VIs to a DLL. Some of these VIs call some of my own LV subroutines, e.g. read_ini.
When I call the DLL functions from a higher level LabVIEW program, which also uses these subroutines, e.g. read_ini, I get some problems. The DLL functions obviously don't find the subroutines.
Is this a problem of the same namespace? Is there any workaround? I have the same effect calling some functions from the LabVIEW library.

Thanx in advance,
Michael

[Ben]

"Is this a problem of the same namespace?"
That may indeed be the correct term. This behaviour has been used to run multiple copies of the same top level VI at the same time. I have not done it personally but I believe the technique starts with an EXE created in LV and then copy it off as different names.

I understand that this is working against you!

"Is there any workaround?"
Try taking a look at this link (see below). In it I was supporting another engineer that was trying to interact will a VI from VB (using a VI in a dll). Jean-Pierre gave us some good feedback. The way I understood what was happening is this.

The VI's inside the dll (or an EXE) run in the memory space of the run-time engine. Some quick hacks I threw together indicated that I could n
ot see the VI's that where loaded in the development environment.



http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000002F920000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0


If someone else wants to jump in here and offer a better answer,
PLEASE DO SO!

Offering what little I know,

Ben

[reke]

Hi Ben,

thanks for your answer and the interesting link. But I think I have the direct inverted problem to yours: You had the problem that a dll called from VB runs in a different memory space than LV, so you have no direct access to your LV application. But my problem is that a dll called from LV runs in the same memory space so that subVIs are recognized where they were loaded first. But I would appreciate a behaviour that the dll only knows its own instances of subVIs and the top level application uses second instances. But obviously this is not so easy in this configuration.
I will take a look, like you have done on "SubVIs in Memory" and "First Call?". This is a good hint. Maybe this will help me to procced with the problem.

I will keep you informed
, but everyone feel free to post any other ideas...

Michael

[Ben]

I am interested in your final solution!

Please keep us updated.

Ben

[Greg_McKaskle2]

I believe that the specifics are that a DLL of the exact same version of
LV doesn't need to load the runtime into the LV dev environment. A DLL
built with a different version of LV will load the appropriate runtime,
since that is the version that the VIs must have.

So this doesn't help much in controlling it, but I think it explains why
sometimes they are in the same memory space and sometimes in different ones.

We don't have any mechanism in current LV for making VIs private to a
DLL or LLB. A quick and dirty fix is to change the name of your subVIs,
giving them a suffix, to make them private.

Greg McKaskle

[Ben]

OK,

After reading Greg's response and thinking a bit, I do have a (rather cumbersome) work-around. Here goes;

LV does a wonderful job of keeping tarck of all those nasty little details like what VI is really being called and are buffers allocatoed correctly, etc, etc.

In your case, this is complicating yur life.

You may be able to get around the issue you are facing by writting a wrapper VI that calls the DLL that has the VI you need shared. Use the wrapper VI instead of the orignal VI anyplace the original would have appeared in your code.

This just might do the trick!

Ben

[reke]

Thank you, Ben and Greg, for your effort. But my solution for now is not to use DLLs. I have only little time left for my project, so I can't spend any time in this problem.
But to the idea with the wrapper VI: I don't believe that this would help, because even the wrapper VI will run in the same name/memory space. And the problem would only be moved one level down, but is not really solved.

But I will come back to this problem, when I have more time and I will post it. I think there must be a solution...

Thanx again,
Michael

[Ben]

I understand time limits!

I was not clear. I meant wrap a "call libray function" configure to use the VI in the DLL.

My fault, please forgive.

Ben