LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FIle path issues in EXE

Please unzip and see the attached Project file. A simple Main and SubVI project to aquire data in main and pass to sub. ( WIN 7 / LV2012).

 

1. The EXE when built, works  only when the  "Use LabVIEW 8.x file layout" option in Advanced option. I also know why this happens - a subVI ( Close Main & Call VI to be loaded.vi) which is inside a folder does not get called if this flat file layout is not chosen.   So what is the way out if i do not have to use the flat file layout ?

 

2. The second thing : If you notice i am passing the data from Main to Sub via a Queue. Is the most efficient method for this and how does it compare with a FG or quite simply a Global variable ? If there any limit to the size of the cluster that i can thus pass via a Queue ?

 

Thanks in advance

Raghu

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 1 of 16
(3,581 Views)

@MogaRaghu wrote:

1. The EXE when built, works  only when the  "Use LabVIEW 8.x file layout" option in Advanced option. I also know why this happens - a subVI ( Close Main & Call VI to be loaded.vi) which is inside a folder does not get called if this flat file layout is not chosen.   So what is the way out if i do not have to use the flat file layout ?

 

2. The second thing : If you notice i am passing the data from Main to Sub via a Queue. Is the most efficient method for this and how does it compare with a FG or quite simply a Global variable ? If there any limit to the size of the cluster that i can thus pass via a Queue ?


1. Based on the current directory structure, your relative paths should be the same.  The only issue I see is that with an executable at all, the Application Directory points to the folder containing the application.  It should not be pointing to something inside of the executable.  Since you are calling VIs inside of the executable, you should be using paths relative to the main VI, not the application directory.

 

2. What exactly is your concern with the passing of data?  Do you need to process every sample that is sent?  If so, the Queue is the way to go.  If you only care about the latest value, then a global variable or Notifier would work well.  The amount of data in the cluster should not be a concern.  What should be a concern is if the subVI needs all of the data.  If not, you are just wasting memory and making the application more confusing.


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
Message 2 of 16
(3,556 Views)

>> Since you are calling VIs inside of the executable, you should be using paths relative to the main VI, not the application directory.

 

While I generally seem to ge the idea, I am not sure how exactly this is done. A small example could help.

 

>> Do you need to process every sample that is sent?  If so, the Queue is the way to go.

 

Yes the final application is a data logging application and i need to process all the data that is read by Main. And also the while loop in the Sub VI is 'controlled ' by the data arriving in the queue. 

All data or latest data ? I guess in my case it makes not difference as i seem to be reading everty single Queue item withou the elements building up. Notifier - well i have not used it so unable to remark.

 

Thanks

Raghu

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 3 of 16
(3,537 Views)

@MogaRaghu wrote:

>> Since you are calling VIs inside of the executable, you should be using paths relative to the main VI, not the application directory.

 

While I generally seem to ge the idea, I am not sure how exactly this is done. A small example could help.


 

 

 


@MogaRaghu wrote:

Yes the final application is a data logging application and i need to process all the data that is read by Main.


Then you definately want to use a queue.


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
Message 4 of 16
(3,514 Views)

What are you trying to do?  There is no documentation in your code, there is little structure, but it almost certainly is the "wrong way to do this".

 

It appears that you want to choose whether to run Routine 1 or Routine 2.  Do you want to run them as "inline" code, i.e. you push a button (or type in "Routine 1") and Routine 1 is executed, and when it finishes, you get another choice?  Do you want to run them "detached", i.e. you choose Routine 1 and this Routine starts running in parallel with everything else, finishing whenever it wants (or, possibly, never), and meanwhile your calling code goes on to do something else?

 

In the first case, I'd just have two sub-VIs (Routine 1, Routine 2) that run, do their thing, then exit.  The Caller would consist of a Case Statement with selectors 1 and 2 -- if 1, Routine1 is executed, if 2 Routine 2.  Very simple, no need for VI server, no problems  (at all building an EXE.

 

In the second case, I'd use Start Asynchronous Call.  I would almost never use VI Server ...  There are numerous ways (typically involving Static VI References and Property Nodes) to get the Path to a sub-VI in an "EXE-independent" way, no worries or concerns about relative vs absolute, no playing with Application Directory.  All that is required is that the files in question are within the confines of the Project (I don't even think they necessarily need to be in a common folder, though all the times I've coded such things, they were ...).

 

So, again, without saying anything about how you want to do, what do you want to do?  [I hope you understand the distinction ...]

 

Bob Schor

0 Kudos
Message 5 of 16
(3,496 Views)

Crossrulz,

Thanks for the confirmation on the Queue. That of course seems to be the right way to go.

 

On the file path, looking at your snippet I am clear about the relative path to the Main. But  I think i must clarify a bit more on the actual issue :

 

1. We are talking about two sub VIs : The first one is the SUBVI01.vi which is the actual user interface.

2. Inside a Event structure this SUBVI01.vi gets loaded and MAIN.vi is unloaded by another sub vi called "Close Main VI & Call VI to be loaded.vi" . 

3. The reason the EXE fails is ( if I dont use a flat file structure )  because the "Close Main VI & Call VI to be loaded.vi" resides inside a folder called "SubVIs" and in the EXE mode,  this folder is not being seen by the application. I am providing the snapshout of the Event structure and the Project file structure to help understand. One way to overcome this is to move all VIs inside the SubVIs folder on to the root folder. But this will be a mess in my final app as i have hundreds of sub vis.

 

Event structure.PNG

FileStructure.PNG

 

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 6 of 16
(3,463 Views)

Yes Bob -  the code that i uploaded has no conventional documentation, formal structure and other such things as it is only a sample code to discuss about a particular issue that i face.

 

Anyway since you asked :

 

1. For the final application the code consists one MAIN.vi and more than dozen SUB VIs which the user chooses from the MAIN depending on the product to be tested.

 

2. And once the user has made the choice of a particular SUB.VI, then the FP of the MAIN.VI is closed and that of the chosen SUB.VI is loaded.

 

3. Hence forth all data communication between MAIN and the SUB happens via designated Queues. 

 

4. I fail to see whats wrong in the above setup - but am willing to follow a better and simple way if there is one.

 

Thanks

Raghu

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 7 of 16
(3,457 Views)

@MogaRaghu wrote:

3. The reason the EXE fails is ( if I dont use a flat file structure )  because the "Close Main VI & Call VI to be loaded.vi" resides inside a folder called "SubVIs" and in the EXE mode,  this folder is not being seen by the application.


That is incorrect.  The VI is in there.  It just is not finding any VIs at the path you gave it.  If you were using proper error handling, you would see this.  From my observations, when using the 8.x format, VI Server goes ahead and looks inside of the executable in the supplied folder.  This seems very weird to me.  What I propose is update the "Close Main VI & Call VI to be loaded.vi" to supply the folder.  Use "Current VI's Path" and strip twice (once for the VI name, again for the subVI folder).  This will give you the folder of the main.


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
0 Kudos
Message 8 of 16
(3,442 Views)

The simplest way I know how to accomplish what you described (and thank you for such a clear description, by the way) is through sub-Panels.  The idea is that your Main consists of its controls/indicators, kept "out of the way", with the space occupied by a sub-Panel structure that will show the Front Panel of whatever you wire into it.  What you wire into it is a Static VI Reference to the sub-VI that you subsequently run.  Here's an example:

Sub-Panel II.png

If I specify "Open" as the VI Name I want to run, this Case puts the Front Panel of Open into my sub-Panel, then runs Open.  Notice that because I gave Open an Icon, this code is more-or-less self-Documenting.  If I had a dozen sub-VIs to select, there would be a dozen cases with similar code.

 

The cool thing about this is that (a) there are no addresses to worry about, so (b) this works equally effectively in Development Mode and when built as an Executable.

 

There are other ways to do more-or-less the same thing in LabVIEW, though this might be the simplest.  Look up (in LabVIEW Help or Google or the Forum) "Plug-in Architecture".  

 

Bob Schor

Message 9 of 16
(3,419 Views)

Thanks Bob.

 

This whole thing is new to me - will give it a try. Though i have earlier used Sub Panels, i had used it the regular way.

 

Raghu

 

 

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 10 of 16
(3,396 Views)