LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

subVIs are unreferenced when creating an .exe?

Solved!
Go to solution

Hi,

 

This is my first post here, so please pardon any mistakes regarding post location, etc.

 

I have been faced with this dilemma for over a week and I can't figure this out.

 

I have a main LabVIEW VI with multiple subVIs. When I run the main VI, everything works as expected, e.g., when I click on a tab/button, the appropriate subVI will open.

 

Now, I create the .exe using the Application Builder using the following steps:

 

I create a project using the main VI and under the My Computer selection, I will add the appropriate subVIs.

 

If I run the main VI under this project (before creating the .exe), everything works as expected again.

 

Then, I press Build Specifications > new > .EXE.

 

In the Source Files selection, I place the main VI as the Startup VI and the subVIs as Always Included.

 

Then, I build the .exe with no errors. 

 

However, once I run the .exe and click on a tab/button to open up a subVI, I get this error:

00engineer_0-1679926222519.png

 

When I click on other buttons to open up other subVIs, nothing happens, i.e., the appropriate subVIs don't open up.

 

I don't understand why the subVIs are not opening especially when everything worked as expected before creating the .exe.

 

I am running in circles with this problem. Super thanks in advance!

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
When I work, theory and practice are combined: nothing works and I don't know why.
0 Kudos
Message 1 of 14
(803 Views)

You should only need to include the toplevel VI. All dependencies that can be determined at build time will be automatically included, so the "always include" box is normally empty. (The only VIs you need to specify in "always include" are VIs that you call by reference derived from e.g. a path, which is typically rare.).

 

How are you calling your VIs? Note that relative paths will change when building (details). If you really need to call a VI by reference, a better choice would be to use static references.

 

Do you have a more detailed error message?

Message 2 of 14
(786 Views)

@00engineer wrote:

Hi,

 

This is my first post here, so please pardon any mistakes regarding post location, etc.

 

I have been faced with this dilemma for over a week and I can't figure this out.

 

I have a main LabVIEW VI with multiple subVIs. When I run the main VI, everything works as expected, e.g., when I click on a tab/button, the appropriate subVI will open.

 

Now, I create the .exe using the Application Builder using the following steps:

 

I create a project using the main VI and under the My Computer selection, I will add the appropriate subVIs.

 

If I run the main VI under this project (before creating the .exe), everything works as expected again.

 

Then, I press Build Specifications > new > .EXE.

 

In the Source Files selection, I place the main VI as the Startup VI and the subVIs as Always Included.

 

Then, I build the .exe with no errors. 

 

However, once I run the .exe and click on a tab/button to open up a subVI, I get this error:


 

Some code examples would be nice, but my first guess would be the VIs are not where they are expected.

 

How are you creating the VI references in your code?  If you've only done the steps you describe, then I expect the VIs you are looking for are now bundled into the EXE as that's the default destination for them. If you are using paths to create your references, you need to take that into account.

 

 


@00engineer wrote:

When I click on other buttons to open up other subVIs, nothing happens, i.e., the appropriate subVIs don't open up.

 

I don't understand why the subVIs are not opening especially when everything worked as expected before creating the .exe.

 

I am running in circles with this problem. Super thanks in advance!


So you get the error on the first one you attempt to open, then nothing happens when you try to open others? What if you try to open them first?

 

If I understand what you are saying here, this points towards another architectural problem. How does your code handle that error? If that reads those buttons has terminated because of it and you have no way of restarting it, then you will indeed have no response to further user input.

 

Again, actual code samples would make this easier to troubleshoot.

Message 3 of 14
(775 Views)

Thank you for your reply!

 

I will take your advice regarding the "Always Included" selection.

 

Below is how the mainVI is calling the subVIs. I inherited this program... A more detailed error message is not displayed.

00engineer_0-1679929067138.png

 

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
When I work, theory and practice are combined: nothing works and I don't know why.
0 Kudos
Message 4 of 14
(768 Views)

A block code snippet is included in my most recent reply.

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
When I work, theory and practice are combined: nothing works and I don't know why.
0 Kudos
Message 5 of 14
(764 Views)

@00engineer wrote:

A block code snippet is included in my most recent reply.


It is not a snippet, just a truncated flat image. Big difference!!! (... and why are there so many local variables?). We typically like to see the VI instead. can you attach it?

 

You have a path defined with a diagram constant (i.e. static). Just use a static reference instead as mentioned IF you really need to call by reference. Normally you would just place the subVI right where the call by reference currently is. Right? Right!

Message 6 of 14
(757 Views)

I don't think my company would be okay if I attached the VI to this public forum.

 

What do you mean, "... [P]lace the subVI right where the call by reference currently is..."?

 

Can you kindly link me to a support page or video regarding this?

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
When I work, theory and practice are combined: nothing works and I don't know why.
0 Kudos
Message 7 of 14
(733 Views)
Solution
Accepted by 00engineer

@00engineer wrote:

What do you mean, "... [P]lace the subVI right where the call by reference currently is..."?


The standard way to call subVIs is just to place them on the diagram! You can browse for it in the palette or drag it to the diagram from windows explorer.

 

(Calling by reference is an advanced topic that you should not even be doing!)

 

altenbach_0-1679935266953.png

 

 

Message 8 of 14
(727 Views)
Solution
Accepted by 00engineer

I assume that event structure is in some sort of loop? Or is this supposed to be a one time menu selection?

 

Outside of a loop, an event structure will only fire once. Hard to say without the VI or more of the code, but that might be why you can only try to launch something once.

 

 


@00engineer wrote:

 

I inherited this program... A more detailed error message is not displayed.

 


Well... that's going to also be part of our problem too. There are no comments or anything in that screenshot documenting the author's intent. Understanding the design intent is always important when trying to figure out why something may have been done that way.

 

Anyway, we can clearly see in that screenshot why this isn't working. <Application Directory>/subVI_Settings_DAQ.vi is no longer the correct path to that VI once the application has been built.

 

What I can't tell you is why the original developer chose to use a Call By Reference Node here, or why they choose to generate the reference that way. Maybe they had a good reason... more likely, they didn't. Call by reference makes sense if you don't know what VI will be called, only that it conforms to that connector pane definition. This could make sense if, for example, you have a folder full of possible choices. However, if you hardcoded the VI path, clearly you know what VI will be called. So why not just use a SubVI node? I can't think of much reason.

 

TLDR: altenbach is probably right. Delete that all and just drop the VI there as a subVI. That's the standard, and simpler, way to make a synchronous call to another VI, and it will work in the EXE without any special configuration.

Message 9 of 14
(705 Views)

Thank you to the both of you for being so helpful to a novice engineer (myself) :).

 

The solution was noted/accepted.

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
When I work, theory and practice are combined: nothing works and I don't know why.
0 Kudos
Message 10 of 14
(687 Views)