LabVIEW
Spawn a process in Labview 7.1
Hi Karl,
In case you are asking for a way to call multiple VIs programmatically and then let go from the caller VI so the callee VI will run by itself independently, you cannot use the "Call By Reference Node" to call the callee VI, since the "Call By Reference Node" will always wait till the called VI finishes execution before continuing. You will have to call the VI with the "Run VI" method as you did in your last VI, but remember to connect a Boolean FALSE constant to the "Wait until done" parameter of the method. To open the front panel of the called VI, use the "Open FP" method before the "Run VI" method:
When calling a VI Template (*.vit) you will automatically get a new clone of the master VI, so calling the above code multiple times pointing at a VI Template, will create multiple clones where the names are the only difference between them.
The above method is somewhat similar to the DynamicProject.zip example I created in this other thread. The difference is that I manually created the unique name of each clone, so the clones could be residing on the hard drive even when called from an executable. The reason for this method is that a clone from a VIT can't be saved by an executable, since the clone requires compiling before saving. Only the Development System can compile a VI - the LabVIEW Runtime Engine can't!
Let me know what you think...
Have fun!
In case you are asking for a way to call multiple VIs programmatically and then let go from the caller VI so the callee VI will run by itself independently, you cannot use the "Call By Reference Node" to call the callee VI, since the "Call By Reference Node" will always wait till the called VI finishes execution before continuing. You will have to call the VI with the "Run VI" method as you did in your last VI, but remember to connect a Boolean FALSE constant to the "Wait until done" parameter of the method. To open the front panel of the called VI, use the "Open FP" method before the "Run VI" method:
When calling a VI Template (*.vit) you will automatically get a new clone of the master VI, so calling the above code multiple times pointing at a VI Template, will create multiple clones where the names are the only difference between them.
The above method is somewhat similar to the DynamicProject.zip example I created in this other thread. The difference is that I manually created the unique name of each clone, so the clones could be residing on the hard drive even when called from an executable. The reason for this method is that a clone from a VIT can't be saved by an executable, since the clone requires compiling before saving. Only the Development System can compile a VI - the LabVIEW Runtime Engine can't!
Let me know what you think...
Have fun!
Message Edited by Philip C. on 07-08-2005 02:22 AM
Hi Shane,
Well, I should have made myself more clear. An executable can launch and run a VI that is located on the hard drive, but the limitation of the Runtime Engine is specific to saving the VI using the "Save Instrument" method. Yes, the Runtine Engine is compiling the VI before running, but it can't save the changes to a VI file. The solution is to use File I/O functions to create a copy of the master VI instead.
Does that make sence? If not, let me know, thanks.
Well, I should have made myself more clear. An executable can launch and run a VI that is located on the hard drive, but the limitation of the Runtime Engine is specific to saving the VI using the "Save Instrument" method. Yes, the Runtine Engine is compiling the VI before running, but it can't save the changes to a VI file. The solution is to use File I/O functions to create a copy of the master VI instead.
Does that make sence? If not, let me know, thanks.
@shoneill wrote:
Hi Philip,
The information that an executable can't compile a VI is new to me. How does this then work with dynamic loading of VIs? I thought that the VI is not compiled when it is saved, and that an executable can load and compile the VI before running it when the VI is called via VI server from an executable.
Shane.
VIs consists always of four parts on disk. There is the front panel, the diagram, the data space and last but not least the compiled code. This last one is only missing, if the VI is not compilable (broken arrow). So LabVIEW stores the compiled machine code together with the VI. When a VI gets loaded in the development environment LabVIEW makes a few checks such as if there is a difference in version number (even minor version such as 7.1 to 7.1.1), the platform the VI was last saved on, subVIs and controls which can't be loaded from where they were supposed to be, or data differences in the connector panes and data structures. If any of these are true, LabVIEW forgets about the compiled code on disk and recompiles the diagram immediately. Since only the development environment has the ability to recompile a diagram into machine code, an application loading into the runtime system will abort in almost all cases of above differences, except differences in minor version numbers and modifications to data structures (clusters) which are cosmetical only.
This has been so since LabVIEW 2.x days and still holds true, although with the new embedded targets it may be that even the runtime system has now some abilities to modify VIs in memory under certain circumstances. It won't save them to disk in that way though.
Rolf Kalbermatter
I don't think LabVIEW really can compile code in the runtime system at all. What has changed in comparison to earlier versions is that certain aspects of interaction between front panel and compiled code have been better isolated in newer versions, to allow remote control of VIs through front panels running in the host system, while the actual code runs and executes on the (embedded) target system. You could say that the LabVIEW runtime system contains actually the linker necessary to glue together the different parts of of a VI hierarchy to a runnable code base, but can't compile the diagram into the actual binary machine code. As far as I know the runtime system doesn't care about the diagram at all, not having any support to deal with it in any way. As such the runtime system is more than just a library of UI widgets and OS communication libraries, as it also contains the linker to create an executable image in memory from the different VIs on disk, but there is no compiler support at all as far as I know.
@shoneill wrote:
Thanks for the clarification of re. compiling of VIs at runtime in an executable.
I get the fact that a VI can be compiled, but that the resulting VI (with compiled code) cannot be written to disk.
Is this a fundamental technological limitation, or simply the way things were done? It would be really nice to be able to use VITs whis way with an executable. I have a few programs which have, until now, only been run within the development environment. I was not aware that these will be broken as EXEs.
I was under the impression that NO compiled code was saved in a VI, but now I know better. It kind of makes sense too now that I think of it.
I'm still a little unsure about a slight discrepancy between what Philip and Rolf have said here regarding the ability to compile any VI at runtime within an EXE. Phil's answer comes closer to that I had originally thought, but according to Rolf, the compiling of a VI at runtime isn't possible.
Which is true? At the moment, I assume that a "normal" VI CAN be compiled (but not saved in the new compiled form) whereas a VIT just doesn't work properly because the saving part, which is otherwise critical, is not available.
Can someone help me grasp the final piece of the puzzle?
Thanks
Shane.
There is no problem in using VITs in a runtime system as far as I know off. At least if you don't want to save them to disk! Aside from the compiler which is not part of the runtime system, the save routines also are excluded. But loading a VIT into a runtime system should still work and should by default create new, uniquely named instances of the VI in memory. The fact that you can't save them to disk does not prevent you from actually invoking those VIs through the run method or even call them by reference as long as you keep the VI reference to it open. It is however a time consuming process to instantiate a VIT, so it is not something I would recommend to do over and over again in an application. Instead create the necessary VI instances at the begin and keep the refnum to them somewhere stored in a LV2 style global or such. Then use them when needed.
Rolf Kalbermatter
