Dynamic VI Call Details

[Gravy_Train]

I have been gleeing details of what actually goes on when a built application dynamically calls a VI form all over the discussion forums, but I don't think that my knowledge is even remotely complete.  I was wondering if anyone can provide in-depth and detailed answers some basic questions?   I am finding LabView's help and documentation extremely sparse.

First of all, when you build an application that makes dynamic VI calls, I understand that you have to include them in the application builder as Dynamic VIs. So does that mean that all of the VIs you name as Dynamic still get rolled up and compiled into the EXE, or they still referenced individually by their MyVI.vi name?  If they are rolled up into the EXE I don't see the value of Dynamically calling VIs and I hope that is not what is happening.  If they are referenced individually by their .vi name,  I would assume that you can make changes to the dynamically called VI without rebuilding the application.  Is that assumption correct?

Next, is it possible to add to the list of VI's that can be called dynamically without rebuilding the main EXE?  In my application my main EXE is reading in a possible list, in the form of a text file, of VI's that it will run by making dynamic calls.  I have written a first set of VIs that I think will be necessary to satisfy my project requirements, but without a doubt, that will change in the future and I would like to write any additional VIs and add their names to the list in the text file.  Will my application be able to dynamically call that new VI without it being added in the application builder under Dynamic VI's.

Next, I am obviously developing my application with software (LabView) that can execute a .vi file.  When I build my application and deploy it to a computer that is using the Run Time Engine, will it be able to execute .vi files or do they have to be in some compiled form?  I know the RTE facilitates the execution of .exe files built from LabView, but does it also include the .vi file may may be called dynamically as well. 

Lastly, how does adding the use of a VI Server effect all of this.  At first I though my application was going to need a VI Server to accomodate the dynamic calls, but now I am not so sure.  I thought I would need to make calls to the VI Server through the localhost to get to the list (and location) of the "pool" of VI's I want to be able to call dynamically.  But if details to answers to question above work out the way I hope, that may not be necessary.  Is that hope valid?

Any other valuable tips and pointers about dynamic calls would be appreciated as well.

Thanks,

Gravy Train

[JeffBoettcher]

---

First of all, when you build an application that makes dynamic VI calls, I understand that you have to include them in the application builder as Dynamic VIs. So does that mean that all of the VIs you name as Dynamic still get rolled up and compiled into the EXE, or they still referenced individually by their MyVI.vi name?  If they are rolled up into the EXE I don't see the value of Dynamically calling VIs and I hope that is not what is happening.  If they are referenced individually by their .vi name,  I would assume that you can make changes to the dynamically called VI without rebuilding the application.  Is that assumption correct?

If you include VIs as Dynamic VIs when building the application, they get included in the EXE file, or you have the option to include them as part of the build but at a custom destination (outside the EXE) as part of the build process.  Either of these are useful in certain circumstances.  You do not need to include them in the build at all though.  A LabVIEW-built EXE can open references to VIs not in the executable, and most things work like if you were in the development system.  Certain VI Server-based operations require the development system to run, but most likely the things you want to do (open, run, etc) would work fine from your EXE.

---

Next, is it possible to add to the list of VI's that can be called dynamically without rebuilding the main EXE?  In my application my main EXE is reading in a possible list, in the form of a text file, of VI's that it will run by making dynamic calls.  I have written a first set of VIs that I think will be necessary to satisfy my project requirements, but without a doubt, that will change in the future and I would like to write any additional VIs and add their names to the list in the text file.  Will my application be able to dynamically call that new VI without it being added in the application builder under Dynamic VI's.

---

Yes, your list of dynamically called VIs can change without rebuilding the EXE, provided of course that the EXE is designed to handle this, and that your VIs are designed properly.  It sounds like you've thought of a reasonable way for the EXE design, in that your EXE reads a file that contains information about the dynamic VIs, so if you add a dynamic VI, you just add it to the list.  As far as designing the VIs properly, some operations (most notably call by reference node use) require identical connector panes from your dynamic VIs.

---

Next, I am obviously developing my application with software (LabView) that can execute a .vi file.  When I build my application and deploy it to a computer that is using the Run Time Engine, will it be able to execute .vi files or do they have to be in some compiled form?  I know the RTE facilitates the execution of .exe files built from LabView, but does it also include the .vi file may may be called dynamically as well. 

---

Your EXE (and therefore the Run-Time Engine) can open VIs provided they were saved in the same version of LabVIEW that the EXE was built with.  You don't need to do anything special to them for this to work; the compiled code is saved every time you save your VI.

---

Lastly, how does adding the use of a VI Server effect all of this.  At first I though my application was going to need a VI Server to accomodate the dynamic calls, but now I am not so sure.  I thought I would need to make calls to the VI Server through the localhost to get to the list (and location) of the "pool" of VI's I want to be able to call dynamically.  But if details to answers to question above work out the way I hope, that may not be necessary.  Is that hope valid?

---

It sounds like you're talking about enabling VI Server access to your EXE.  Based on what you've described, I don't think this would be necessary.  Your EXE would be acting as a VI Server client, in that it is opening references to VIs outside of itself, and running them "as part of your EXE".  You only need to enable VI Server for your EXE if you wanted other EXEs or the LabVIEW development system to be able to access things from within your EXE.

Hope that helps!

[JeffBoettcher]

Quick addendum - In order for an EXE to be able to open a reference to a VI, it must not only be saved in the same version, but also on the same platform (Windows / Mac / Linux) as where the EXE was built.

[Gravy_Train]

OK.  Due to the "over whelming" response to my post, I had to figure everything out myself by trial and error.  I did figure out that dynamically called vi's can both be rolled up into the EXE or the application builder can placed them in either the destination directory or the support directory created by the application bilder.  If they are placed in the destination or support directory, they are placed as *.vi files and can be edited or replaced, as long as they keep their file names that were specified in the application builder, without having to rebuild the application.  One thing that I did have problems with though is the file path used when trying to specify the support directory by stripping the path of the EXE and rebuilding the path to the support directory.  No matter what I tried, I errored out with a "not a path" error.  I think it has something to do with the fact that I need to strip the path of the EXE twice, but not matter how I stiped or built the path, it didn't work.  So unless someone pipes up here, I will have to figure this out by more trial and error.  I did, however, get everything to work if I specified the dynamic VIs to be placed in the destination directory following the same strip path of the EXE routine.

If my application and my dynamic vi location is going to reside on the same computer, then I do not have to use a VI Server at all, which simplified things greatly.

I also found out that ALL dynamically called vi's must be identified in the Source Files section of the application builder.  New vi's to the the "pool" of dynamically called vi's can not be run in the main application unless the main application is rebuilt.  Even if there are no changes to the main application code itself, the addition of the new vi must be kept track of in the EXE somewhere.

The only question that I still have, that I don't think that I will be able to figure out by trial and error, is it possible at all to programatically add to the list of Dynamically called VIs in the EXE, such that I do not have to rebuild the application every time I add a new VI to call dynamically?

Thanks,

Gravy Train

[Gravy_Train]

I think that I was writing my respoings to my own post as you were writing a reply as well.  I was kind of disppointed that the number of responses as I was writing it, thank you for your response.

But like my post says, I did figure out most of it myself.  The only place I disagree, or perhaps havn't had enough trial and errors, is the references to VI that were not included in the Dynamic WIs and Support Files in the application builder. It errors out with "Error 7 occured at Open VI Reference" when I try and call a VI not included in the application builder.  I understood that if I were to make calls to "unknown" future vi's that I needed to standardize on a common connector pane, and I have.  Can you please expand on your comment " ... provided of course that the EXE is designed to handle this, and that your VIs are designed properly".  I think that I have done so.  The only deviation from you descprtion of proper design is that I do not use a Call by Reference Node, I use an Invoke Node because I am placing the front panel of the dynamically called vi into a subpanel of the EXE.

[JeffBoettcher]

I went and double-checked this in 8.2 as I probably hadn't done it since 7.x, but it behaves the same way it used to.

If you're getting an error 7, most likely it is a problem with the path you're sending to the Open VI Reference function, as that is a file not found error.  Note that relative paths may behave differently in a built executable, because the location of the dynamic VIs relative to the top-level VI might be different after they are packaged for distribution.

This is an excellent example of how remotely debugging executables (new feature in 8.0) can be useful.  You might check the LabVIEW Help for that if things still aren't working properly for you.

[Dennis_Knutson]

Have you looked at the shipping example called 'Plug In Example'? That shows how you can look in a folder to find VIs that you want to call dynamically. Then you don't have to include the dynamic VIs in the built executable at all. A word of warning though. When you don't include the dynamic VIs, any subVI that the dynamic VI uses will not be included either. In order for the dynaimc VI to be called, you will need to do an application or development distribution of the dynamic VI.

Yes, you do need to do an extra strip path in an executable. If you use Current VI's path, in the development system a path might be c:\folder\example.vi. When built, it becomes c:\folder\app.exe\example.vi. You can make it work in both development and exe by using the application property App.Kind. Wire this to a case statement and in the run-time case, do the extra strip path.

[Gravy_Train]

Thanks guys.  The error 7 problem I was getting wast, I'm sorry to say, a bone head mistake on my part.  I forgot to move the my "new vi" into the destination directory of the target system.

Dennis, I have not used a source distribution before and I am a little unsure of what it provides.  I am now about to go read about it, but any experienced advise is welcome. 

[Dennis_Knutson]

Source and application distributions are nothing more than an llb. With a source distbution, the block diagram is removed.