LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open VI reference and paths problem

Hi,

 

in my project I need to have a VI running independently from the calling VI so I use VI Server and "Open VI reference" to run the VI. However this is not without problems. The VI that I run is not in the same folder, as the caller VI and also not on a fixed location on disk, so I use relative paths (something like "..\subfolder\myVi.vi"). This works in the project and .exe but not e.g. in a .llb file where there seems to be no folder structure anymore.

 

Actually I'd prefer if this would not use paths on disk at all but if I could somehow create a reference to another VI in my project and it would even work if the VI's location on disk changed (and is updated in the project). I think it is quite confusing that I have to care about physical location of the VI here when I use the project browser for everything else. Is there a way to accomplish this? Or is there even a better way to start a VI that keeps running even after the caller stopped?

 

Thanks,

 

Tobias

0 Kudos
Message 1 of 7
(3,362 Views)

Hi Tobias,

you can make it relative to the vi in which you call your vi dynamically. Use the "Current VI's Path function" to see where you are and react on it.

 

Mike

Message 2 of 7
(3,358 Views)

Hi,

 

thanks for your reply. Still, this won't make the situation better if the VIs position on disk changed (while the project structure stayed the same) or if I build an .llb where there is no folder structure anymore. It will only help if the location of both VIs changes but they stay the same relative to each other. But in this case using relative paths also works. Or did I understand you wrong and you meant something else?

 

Thanks,

 

Tobias

0 Kudos
Message 3 of 7
(3,355 Views)

Hi Tobias,

if both vi's stay relative to each other all the time, then i would use the "Current VI's ..." function from the caller and create the path of the other vi. In an llb and in an executable all vi's are located side by side. If you have the path of the caller, then you can react on the situation.

 

Mike

Message 4 of 7
(3,350 Views)

The OpenG toolkit has a function called Current VI's Parent Directory, which returns the folder where the VI is stored, you can use relative paths to build your path.

 

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 5 of 7
(3,348 Views)
Ok, so you're saying I should check the path and if it is an .llb or an .exe I should do something different? I guess this would work. Still, I'd prefer a solution that is independant from physical location. But it seems that is not possible, right? Thanks anyway!
0 Kudos
Message 6 of 7
(3,348 Views)

As far as I've seen, every VI has the path ../Application.exe/currentvi.vi when you are running in a build.  Therefore, to open another VI you have to strip the current vi's path once, and add the other vi. 

 

I have written a VI that determines whether or not I'm running from a build, it is attached.  It returns true if you're in a build, and also the current vi's path stripped once giving you ../Application.exe.

 

The way I use the VI is pictured below.  I send the stripped path Is Executable returns and the relative path (minus the vi name) into a Select icon which is wired to the boolean Is Executable returns.  Then I add the other VI name to the path.

 

 

 

Message Edited by elset191 on 04-21-2009 10:43 AM
--
Tim Elsey
Certified LabVIEW Architect
Download All
0 Kudos
Message 7 of 7
(3,308 Views)