LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

vi's loaded when executable is launched

Hello everyone,
 
I have a problem concerning the Application builder. I've created an application, a top-level vi is included and some vis that are dynamically called from the top level vi. When the application is launched, only the vis that are statically included in the top-level vi (on its block diagram) are loaded in the memory space of the executable. I thought that all the vi's will be loaded when the executable is launched so they could be called by opening a reference with only the name of the desired vi included in the executable. Since it is not loaded in memory, an error occurs. What is the behaviour when an executable is created and launched? If Labview uses in the same time some vi's having the same names as the vis included in the executable, will there be any errors (or rather warnings) concerning these vis (if a vi is already in memory and another vi, having the same name the first vi in memory is kept and a warning is given to the user; since an executable has its own memory space - different from Labview's memory space -  this kind of conflicts should be avoided)?
 
I would have another question concerning a particular context. The same top level vi should act as follows: it should dynamically call another vi, it should check if parameters have been given for its execution. If parameters were not given it should open the front pannel of the called vi (without executing it), it should wait for the user to choose parameters on the front pannel of the dynamically called vi, to execute it and wait for the value returned by the called vi. Once it has returned a value, the top-level vi should get the returned value (that will be displayed in a string indicator on its front pannel) and afterwards carry on its execution. I have tried to do so using Run and Get Control Value methods from the Invoke node but the behaviour wasn't as expected. Is there any way to accomplish this behaviour?
 
Thanks alot for your help,
Paul. 
0 Kudos
Message 1 of 5
(2,566 Views)

If dynamic VIs were loaded into memory when the top-level VI was launched, then they would be static and not dynamic. The whole point of having dynamic VIs is that they are only loaded when you call them. If you get an error when trying to open a reference to a dynamic VI, you either have the wrong path, you didn't include them in the build as dynamic VIs, or you haven't included in the build as support files. Getting the correct path is usually the biggest mistake people make when they first start using the app builder and dynamic VIs or other exteranl files. If you use the function Get Current VIs path in the development mode, you might get a path like c:\folder\example.vi. When built, it will be c:\folder\application.exe\example.vi. You have to do an extra strip path to get to c:\folder. You can mimic the behavior of an exe in the development mode by creating an llb from the top-level VI. You can save a dynamic VI to the llb or keep it exteranl if that is the way you want to distribute dynamic VIs.

Prior to LabVIEW 8, if your executable contained a subVI of the same name as a dynamic VI, when you called the dynamic VI I don't believe you would get any kind of warning. Since a VI of the same name would already be in memory, it would use the VI in memory.

I'm not quite sure I understand your last question. How are parameters passed to the dynamic VI? Are they from front panel controls? It would seem to be a simple problem to check to see if they have empty or default values when a "run" button is clicked. If the parameters don't come from your top level VI, where would they come from?

0 Kudos
Message 2 of 5
(2,549 Views)

First of all, thanks a lot for your answer. I will try to be more specific. Let’s suppose the following scenario: an executable will be created from some source vi files. In the executable, there will be one top-level vi and a lot of dynamically called (from the top level vi) vis. A vi will run under Labview and will dynamically call the top level vi from the executable, telling it which vi it should call dynamically (amongst the ones complied in the executable) and giving certain parameters. This vi, running under Labview, will have some common sub-vis with the vis that are dynamically called vis from the executable through the top-level vi. Normally, if two vis are executed, if they have sub-vis with the same name (even if the content and is the behaviour different), when the first vi is loaded in the memory, all the sub-vis are also loaded. Warning messages (of the kind: the vi expected to be at … was loaded from …) will appear when the second vi is launched. Is this also true when a vi run under Labview has common sub-vis with an executable? Since the executable will load sub-vis in its own memory space this kind of warnings should be avoided.

 

I would like to obtain the following behaviour with the executable (the top-level vi): it should first check the value of a control on the front panel (that will contain information to be transmitted to the vi called dynamically). If the control is an empty string the front panel of the vi that is being called should open and wait for the user to perform actions on its front panel controls (that will generate information that will be used when the vi is executed). After the execution, the top-level vi should recover the result of the execution of the called vi (which will consist in the content of a string indicator). The problem is that the vis should be executed in a certain order and some vis should still be in memory in order for the execution of some others to succeed. Since they are called dynamically, after the call the reference closes, the front panel of the vi is closed and they are not statically included in the block diagram of the top-level vi so they are not in the memory any longer at the end of the execution. Launching the application with new parameters will fail since the vi that was called before is no longer in the memory. Is there any way to keep them in memory? I have tried to leave the reference open but, when the application finishes its execution the reference is closed anyway.  I have also tried to run in parallel another vi that will open the references and will continue running while the top level vi is open but, I am not able to find a way to call it, recover the reference it has open and pass further on (since the vi will run in a loop the top level  vi that calls it waits for it to end before going on).

 

Thanks a lot for your help.

 

0 Kudos
Message 3 of 5
(2,543 Views)
This is what I would do with the Call By Reference Node.
Download All
0 Kudos
Message 4 of 5
(2,538 Views)
Thanks alot for your help.
0 Kudos
Message 5 of 5
(2,527 Views)