LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamically Launch VI Runtime vs Development environment

Solved!
Go to solution

 

Problem: When I dynamically launch a VI in runtime environment, the front panel loads but the VI does not run.  However, it works propertly in the development environment.

 

 

 

Background:  This is part of a larger Vi that is basically a menu that launches other applications (executables, other menus, VIs, etc.).  The menu and all of its settings are populated at run time from a database I maintain.  For the dynamically launched VIs, I either launch them in a subpanel or stand alone.  I have attached the block diagram of the subVI that launches my VIs.  In it, I first parse out all of the settings passed through from the main VI, create a reference to the VI that will be launched.  Next, if it is to be launched in the subpanel, I insert it into the subpanel then center it based on its and the subpanels sizes.  Next I check if the VI is already in memory, if it isn't I run it then activate the FP.  If it is in memory, I check if it is running, if it isn't I run it. 

 

The subVI is a prototype and I am aware it right now doesn't have great error handling, most of the error handling is done in the main VI but I know I should add more  in this subVI as well. 

 

 

 

When I run my program in the development environment everything works fine.  When I create an executable, I run into issues.

 

 

 

I include the dynamically launched VIs in my exe build's 'always included'.   When I launch them in the subpanel, there is no error and the FP is loaded but the VI doesn’t run.  When I launch them outside of the subpanel the dialog box where subVI are being loaded pops up very briefly, then disappears, and nothing else happens.  The exception is if I use an extremely simple test vi (a while loop with a stop button) it runs properly. If I add any complexity to the vi, (e.g. add a single sub vi) it no longer works in the runtime enivironment.

 

 

I need to be able to run the main Vi as an executable in order to deploy it.  Any ideas what my problem might be?

 

 

0 Kudos
Message 1 of 8
(4,389 Views)

torry7 wrote:

I include the dynamically launched VIs in my exe build's 'always included'.   When I launch them in the subpanel, there is no error and the FP is loaded but the VI doesn’t run.  When I launch them outside of the subpanel the dialog box where subVI are being loaded pops up very briefly, then disappears, and nothing else happens.  The exception is if I use an extremely simple test vi (a while loop with a stop button) it runs properly. If I add any complexity to the vi, (e.g. add a single sub vi) it no longer works in the runtime enivironment.

 

 

I need to be able to run the main Vi as an executable in order to deploy it.  Any ideas what my problem might be?

 

 


What is the simple single sub-vi that you are adding doing?
Are the dynamically lainched vi still ending up with a while-loop?

Like any other standalone running vi, a dynamically launched vi need to have something in it that is continueing its execution, else it will stop.

 

A vi in a subpanel that has stop, is not that easy to spot when it is a exe. The front panel is still looking like it is running.
That is because you are runing the exe in RunTime Engine.

0 Kudos
Message 2 of 8
(4,366 Views)

@dkfire wrote:

What is the simple single sub-vi that you are adding doing?
Are the dynamically lainched vi still ending up with a while-loop?

Like any other standalone running vi, a dynamically launched vi need to have something in it that is continueing its execution, else it will stop.

 

A vi in a subpanel that has stop, is not that easy to spot when it is a exe. The front panel is still looking like it is running.
That is because you are runing the exe in RunTime Engine.


The VIs I am launching can run stand alone.  I will attach an example of the VIs I am trying to launch.

 

When I talked about adding a subVI, I meant adding any subVIs to my 'test' VI that I was launching.  I will attach examples of this as well.

 

I don't think it is an issue with the VIs I'm launching not operating properly since they run fine in the development environment.

 

Attached VIs:

 

Change_Password.vi

This VI is one of the VI I am attempting to launch for the application.  It will not run properly for you since you do not have the .ini file I read from or the database, but it should give an idea of the type of VIs I am trying to launch.  This VI runs properly stand alone or when launched dynamically from the Development environment.  When launched from the Runtime environment, the FP loads, but does not run.

 

Test.vi

This is a VI I used to test the functionality of my dynamic launching method.  It works in both the Runtime and Development environments.

 

Test2.vi

This is the Test.vi modified slightly so that it includes an subVI (in this case 'Simple Error Handler.vi').  It works when launched from the Development environment but not from the Runtime.  It, like my Change_Password.vi, only loads the FP but does not run.

Download All
0 Kudos
Message 3 of 8
(4,340 Views)

I tested the launch of your 3 VI's (I disabled a few of the sub-vi's in the Change_Password.vi) and they work either in Labview or as an executable. I do not dynamically launch the VI's the same way you do though. Sometimes, using the VI path can be tricky, especially in an executable. I show below how I dynamically launch VI's. I hope it helps.

launch test2_BD.png

Marc Dubois
Message 4 of 8
(4,299 Views)

Thanks md,

 

It doesn't quite solve my problem but I think it gets me closer to identifying the source of the problem.

 

I made some dummy code and launched the VIs using an explicit reference like you instead of creating the reference by the path.  When I did this, the VIs I launched worked in both Development and Runtime.  Unfortunately for my application I need to be able to create the reference by the path. 

 

Does anyone have any ideas why in the Development Environment both methods of creating the references works, but in the Runtime Environment the explicit reference works but creating the reference by the path does not?

 

I have checked the path to the VI in both environments and the path is correct.

 

 

0 Kudos
Message 5 of 8
(4,256 Views)

 The problem might be related to the path you use in the executable. Paths are not treated the same way in an executable than in the developement environment. You might have a look at:

 

http://digital.ni.com/public.nsf/allkb/EEE8A5650DAC28558625762F0070A384

 

The explicit references get rid of the path problem in executables. If for whatever reason, you must use a path, you can try to get the path from the explicit references instead of typing them into the code. See below :

 

launch test2_BD.png

 

 

Marc Dubois
0 Kudos
Message 6 of 8
(4,240 Views)
Solution
Accepted by topic author torry7

Hi torry7,

 

The big difference with a statically-linked VI reference is that the compiler knows at build time that a VI will need to be loaded and will include any dependencies of that subVI in the executable.  You noted that you're already including these subVIs as "Always included" in the build specification, however, so unless there is some sort of path conflict that should work.  Although- have you modified the destination of these VIs in the build specification?  Are they still included within the executable, or have they been moved to an external directory? Are you attempting to call any of these VIs reentrantly?

 

Based on your observations, it sounds like your calling VI (LaunchVI) doesn't return any errors, is that correct?  It seems to me that a dependency or reentrancy issue is most likely.

 

 

For other things to try, refer to this KnowledgeBase article:

 

KnowledgeBase 3LBHGHZH: Why Does My Plug-In Application (EXE) Not Dynamically Call My Plug-Ins Correctly?

http://digital.ni.com/public.nsf/allkb/4CB098B512EFB2B786256FFF00813037

 

Regards,

 

 

Tom L.
Message 7 of 8
(4,234 Views)

md,

 

I don't think the issue is related to the path I am using.  I am pulling the path from a database and it is an absolute path not relative so the file layout differences between executable and development environments should not matter. 

 

Tom,

 

I think you are on to something with the dependency issue.  I am including the called VIs in the build, they haven't been moved or modifed, and my calling Vi does not return any errors, so I'm not sure why I am getting this issue.  However, I tried some of the methods layed out in the KnowledgeBase article you linked to and was able to get the called VI to function by creating a source distribution that included all the subVIs, the vi.lib, user.lib and instr.lib VIs and calling the vi from that folder.  I still have a bit of work to do to because I would like to avoid having to create a source distribution for every VI I call, since it is a bit messy having an folder containing hundreds of VIs for each VI i need to call dynamically.  I think I am on the right track now though.

 

Thanks,

 

Torry

0 Kudos
Message 8 of 8
(4,203 Views)