LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

I can't find my dynamic VI from my EXE

Solved!
Go to solution

First time building a VI with dynamic calls in 2009. Before I would just change the number of strip paths before compiling because I was too lazy to add the code that asked whether it was running as a VI or EXE. So now with 2009, I'm excited because I thought it would take care of it for me.

 

On the computer the path is as follows: .../VIs/Data Handling/Offsets/Offset FG.vi

 

In the EXE, the path that the EXE is looking for is .../DAQ.exe/VIs/Data Handling/Offsets/Offset FG.vi

 

But it doesn't find it. I have the entire VIs folder Always Included. I can't figure out how to list all VIs in memory while debugging the EXE? I'm not sure if the path is wrong, the build is wrong, or...?

0 Kudos
Message 1 of 10
(3,628 Views)

Are you building your path using the "Application Directory.vi" as a starting point?

If not, this might eliminate the problem and also simplify your code.

      >Programming>File I/O>File Constants>Application Directory.vi

 

App Dir Hlp.png

 

James

LabVIEW 5.0 seems so long ago...
Message 2 of 10
(3,604 Views)
You can get all VIs in memory with this:

VIsInMemory.png


Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Message 3 of 10
(3,601 Views)

JRJONES I have not used the Application Directory. For this project I tried to keep all of the callers in the same level as the dynamic VI so that I could just strip once and then add the name of the dynamic VI. So .../Offsets/FG Caller.vi is calling .../Offsets/Offset FG.vi, and there is a strip and a build in the caller. Anybody seem something I'm missing there? It works as a VI. 

 

JCARMODY, I cannot figure out where you got Application>AllContexts? AllContexts does not show up on my property node under Application?

 

Message Edited by deskpilot on 05-03-2010 12:23 PM
Message Edited by deskpilot on 05-03-2010 12:23 PM
0 Kudos
Message 4 of 10
(3,589 Views)
That's a LV2009 snippet.  Here's a 8.2 version.
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 5 of 10
(3,580 Views)

You said these VIs are added as Always Included, however, you didn't mention the Destinations or Source File Settings.

Is the Destination for these files the EXE or a separate folder location?

If a separate folder, does that structure match that in the development environment?

 

Good luck, James

 

 

LabVIEW 5.0 seems so long ago...
0 Kudos
Message 6 of 10
(3,567 Views)

I guess you are running into the same problem I faced some time back.......

 

While making executable, in Advanced section, check  "Use 8.2 layout"....and build EXE.....This solved my problem..I hope this will solve your problem too.....

Message Edited by Anil Reddy on 05-03-2010 01:04 PM
Anil Punnam
CLD
LV 2012, TestStand 4.2..........
0 Kudos
Message 7 of 10
(3,563 Views)

Ya, so I'm a little slow, forgot I could just drag and drop the snippet. I didn't realize it had to be running in the EXE, I thought I could just run it in parrallel, but I only get a return when it is in the EXE. But then I'm not sure what that gains me. I know what files are in there, I just don't know where they are?

 

The project has autopopulating folders. The top level of the project under My Computer includes 1. the Startup VI and 2.a folder called VIs. The VIs folder includes everything in the project except for the startup VI. The VIs folder is placed in Always Included. The destination for all of the support files are left default. I thought in 2009 this was supposed to preserve the file layout inside of the EXE?

 

If I go to 8.x file layout, this just gives me a flat file structure with all of the VIs one level below the EXE. I can change the code to accomodate this, but I would have to remember all of the places this would affect, which could take awhile.

0 Kudos
Message 8 of 10
(3,550 Views)

So maybe Jims snippet did tell me something. Should the dynamically called VIs be in memory when the EXE is run, but before the EXE calls them? They are not.

 

I'm very frustrated at this point. I built an example project, duplicated the heirarchy to the callers and the callees, the settings in the build, everything, and it works fine.

 

Back in the real project, I added a thisVIspath function to the caller, and its right where I expect it to be, but it still does not find the callee. So I added the function to the callee and included it as a startup VI. Its path is right where I expect it to be, and now it is found.

 

What am I missing. The VIs folder has a default source file setting. The caller and the callee are left Same as Caller. I was unsure about this, but it works in my example. Is something corrupt in the project?

0 Kudos
Message 9 of 10
(3,514 Views)
Solution
Accepted by topic author deskpilot

I never thought I could spend so much time troubleshooting a %&(*)$%^*$)%%) space constant. AGAIN! The string driving the build path that was driving the Open VI Ref had a space at the end. In my defense, I did not type this constant, but I guess not much of an excuse. I would not have expected the VI to work with this error, I guess thats why I hadn't checked it before now. I suppose the VI version worked because the project was open and this allowed the Open VI Reference to find it even though the name was not entirely correct????

0 Kudos
Message 10 of 10
(3,488 Views)