LabVIEW
Spawn a process in Labview 7.1
Yes, a runtime system can only load VIs saved in the same LabVIEW version (except minor VI version difference) and on the same architecture. A runtime system on Linux while being x86 based can NOT run a Windows compiled VI. Platform independance of LabVIEW is broad and almost unpreceded but not down to the binary level, as the compiled code is not byte code as in Java or Python for instance, but directly real machine code instructions. Including the compilers and intelligence a LabVIEW development environment in the runtime would:
@shoneill wrote:
Thanks rolf,
That's helped clear it up a little more for me. Sorry for the presistent questions, but here's another one......
If the EXE isn't capable of compiling doce, does this mean that an EXE cannot load a VI dynamically which was saved on an "incompatible" machine? This is something I always thought was possible. Not that I've ever had to or even tried to do this, but I thought it was possible to (for example) compile an EXE on a Windows maching (X86 architecture) and then copy a VI from a mac environment (not containing any OS specific calls of course) to be dynamically loaded by the EXE.
Your explanation rules this out. I'm not saying this is of any real practical importance to me at the moment, but it's something I'm curious about. (Meeow, THUD!)
Can someone confirm this? This truly surprises me as I thought the "platform independence" of LV would at least extend that far.
Does this mean that on a Linux box, any VIs to be loaded dynamically must be saved on a hardware-compatible machine?
Just a Q, as Linux will surely gain in importance in the future.....
Shane.
1) Bloat the runtime engine considerably
2) Possibly create difficulties in that for certain recompilations user interaction may be required in one form of the other such that sooner or later part of the editor would have to be included in the runtime system too.
3) Reduce one more incentive to use the development system for quite some circumstances
Just try it out and you will see the error message when trying to load a Linux VI into a Windows runtime system.
Rolf Kalbermatter
NOTICE!!! The above statement is WRONG! The LabVIEW Runtime Engine does NOT have the power to compile a block diagram, but can only run an already compiled code.
@Philip C. wrote:
...Yes, the Runtine Engine is compiling the VI before running...
Sorry for the misinformation!
Hi Rolf,
Thanks for clearing out this question!
It's absolutely correct that a VI is stored in four different parts:
Here's a great way to demonstrate that the compiled code actually exists:
I hope that this makes it easier to understand what goes on behind the scenes.
Have fun!
Thanks for clearing out this question!
It's absolutely correct that a VI is stored in four different parts:
- front panel
- block diagram
- compiled code
- data space
Here's a great way to demonstrate that the compiled code actually exists:
- Create a runnable VI and save it.
- Click Ctrl+i and go to Go to "VI Properties » Memory Usage".
- Notice the four different parts mentioned above. Notice the size of the "Code".
- Make the VI non-executable by breaking the code - e.g. delete a necessary wire. Save the VI.
- Notice that the size of the "Code" now is practically 0 (most likely 0.2 KB) - this is because the VI couldn't be compiled and therefore no compiled code was saved.
I hope that this makes it easier to understand what goes on behind the scenes.
Have fun!
Message Edited by Philip C. on 07-13-2005 12:28 AM
Hi Shane,
@shoneill wrote:
... I apologise for pulling this thread off-topic.
Do not apologize for the way this thread turned out - on the contrary, it made me (and even some LabVIEW developers) question our presumptions on when and how the compiler works.
This discussion has also made me look into the possibility of creating an in-depth document that describes exactly what goes on behind the scenes when a VI is being build and compiled, and how the execution is performed.
I really enjoyed investigating this topic, thanks!
