LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

multiple instances of a subVI - problem if running as executable

Hello LabVIEW gurus,

I have written an application, which uses a VI-template to create multiple instances of this subVI which are
running independently. I use 'Open VI Referece' and the 'Call By Reference Node' VIs. My application works
fine if it is executed in the LabVIEW development environment.

But if I use the Application Builder to create a stand alone program, the 'Call By Reference' method seems
not to work. The program works without any error message, but the subVIs created by call by reference
deliveres no results. I suppose the subVIs are not created properly.

Has anybody an idea or hint to solve that problem. Are there any known issues with 'Call By Reference Node'
and 'executables'. Are there special points to pay attention for?

I have that problem with LabVIEW 7.0 and 7.1 (Windows2000 and WindowsXP(SP2))

Thanks for any hint that could be helpful.

Steffen
0 Kudos
Message 1 of 13
(3,938 Views)
I seem to recall that paths are the key to this problem.
 
When you create an EXE the path will be different from the path used by Labview. Its all to do with current directorys and search paths.
 
0 Kudos
Message 2 of 13
(3,938 Views)
Thanks for that hint, but this problem is well known and I use a VI that deliveres the same
VI path if it is executed in LabVIEW or used in an executable. So I can exclude that point as reason
for my problem.

Thanks, any other ideas?

Steffen

0 Kudos
Message 3 of 13
(3,933 Views)

Can you post a simplified example,

I often find the problem when I try to simplyfy the problem into an example I would have posted..

0 Kudos
Message 4 of 13
(3,932 Views)
That is correct if you are using the Current vi's path function. When you get the path in the development environment it will just give ...\foldername\viname.vi. But if you build an executable from the same vi and run the executable on the LabVIEW Run Time Engine it will give the following path instead ...\foldername\appname\viname.vi. So you would have to use the strip path function to get the correct path.
 
Mohadjer
NI-DK
0 Kudos
Message 5 of 13
(3,931 Views)

soory I was not that fast with my writing....

0 Kudos
Message 6 of 13
(3,929 Views)
Yes, I will prepare an simplified example to demonstrate my problem.
I will post it here, but it will takes time, because I have to do some other
tasks at the moment, so stay tuned, please.

Steffen


0 Kudos
Message 7 of 13
(3,926 Views)
Sorry for the obvious question but did you include the templates as dynamic VIs when building the application? Since these VIs are not part of the Top Level hierachy, they have to be include explicitely as dynamic VIs.

By the way, when VIs are included as dynamic VIs they are put in the internal LLB of the executable file. When opening the VI reference, that internal LLB is first looked into for a VI of that name and if it is found there the actual path is ignored. The internal VI is opened so you don't have to care about absolute paths when using inluded dynamic VIs e.g. you can leave paths used during development. The actual path is important only when the referenced VI is located outside the executable.


LabVIEW, C'est LabVIEW

Message 8 of 13
(3,920 Views)
Yesterday, I announced to post a simlified version of my application. I have created that version and tested
it as executable and it runs perfectly. So there seems to be another reason for my problem. It looks quite curious.

Steffen.

0 Kudos
Message 9 of 13
(3,896 Views)
The problem is still alive Smiley Mad

One difference between the simlified version that works properly and the version that has the problem
is that the last one is calling external DLL functions.

It's really strange.

Is there anybody who has an idea concerning my problem?

Thanks

Steffen

0 Kudos
Message 10 of 13
(3,887 Views)