LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 8.x File layout issues

Refer the attached ZIP which is a simple two VI project. One VI launches first and upon user coomand launches another VI and aborts itself later. 

 

Works fine as such in both design and EXE form. But only when I choose "LabVIEW 8.x file layout "mode in the advanced tab of the EXE Build Dialog. 

 

What i have shown is a simple case but in actual projects I have many nested folders for sake of grouping identical VIs ... like Sub VIs / Controls  etc

 

I always have a problem making them work as intended as a EXE. The additional layer of folder that comes in when made as an EXE is the problem.

 

Is there any better way of handling the launch of the Main vi ? 

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 1 of 6
(2,539 Views)

Since you are dynamically calling VI, you need to use relative paths relative to the calling VI.  So instead of using Application Directory, you should be using Current VI's Path.  And instead of converting back and forth between strings and paths, use Build Path and Strip Path.

 

Some other notes on your Start.vi:

1. Your buttons really should have a mechanical action of "Switch When Released".  And then you can put the terminals in their respective value change event cases.

2. No need to call the Quit LabVIEW function.  Just close the panel.

3. You actually do not need the While Loop.  Regardless of which button is pressed, your VI should stop.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Download All
0 Kudos
Message 2 of 6
(2,515 Views)

When I need a path to a VI, either for using Run VI or (my preferred method) Start Asynchronous Call is to use a Static VI Reference (on Application Palette), browse for the Path of my VI in the Project, then use a Property Node to "extract" the VI Project.  This takes care of Relative vs Absolute and works whether you are in the Development Environment or have built an Executable.  Here's what it looks like:

Path to VIs.png

You might recognize the Icon you created for Main, and the Icon you failed to create for Start (demonstrating the virtue of creating Icons, even if a simple Square with "Start" written in it, to help identify sub-VIs on the Block Diagram).

 

Bob Schor

 

Message 3 of 6
(2,508 Views)

@Bob_Schor

 

Looks interesting .. let me give it a try.  SO the idea is to creat the references for the different VIs and use them in dynamic calls ?

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 4 of 6
(2,504 Views)

@Crossrulz

 

Well the way I was imagining the structure of folders is that the Application Folder was the container for all the VIs ! I was wrong. I happened to check the VI hierarchy and the setup became clear where the Application Folder was one step below the Start VI as i had referenecd it there ... so there is no way to get Main from there.

 

Noted your other tips thanks.  Right now this one works well .... any improvements to this apart from the points you already mentioned ?

StartVI_Revised.png 

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 5 of 6
(2,502 Views)

No, the idea is when you need the path to a VI, let LabVIEW find the Path for you.  This works when the VI and all the related routines are held in a LabVIEW Project (which knows the paths and the relative paths, useful when going from Development to Application modes).  When you attempt to build the path yourself, it is easy to make a mistake (I hate making mistakes, so if I can pass the buck to LabVIEW, I'm happy to do it).  Note that this also works if you use Start Asychronous Call to start a detached VI running (my by-far-preferred method for running asynchronous processes).

 

 

Bob Schor

0 Kudos
Message 6 of 6
(2,491 Views)