Linux VI with Runtime Engine Only

[Wiebe@CARYA]

Hi,


We're trying to start a VI on a Linux system, with only the runtime engine installed. But we're having a few problems...


First, if the runtime engine installed without errors ("rpm --install labview71-rte......i386.rpm" and "rpm --install labview-rte-aal......i386.rpm") how can I know for sure that it's working? I can't find any file that indicates that it is installed...


Is it possible (just like under windows) to start a VI with only the runtime engine? What should I call on the shell to start a VI?


Is it possible to run a windows VI under Linux, with only the runtime engine? I read somewhere on www.ni.com that to run a VI a rte of the LabVIEW version used to build the VI is needed. But is LV7.1 for Linux the same version as LV7.1 for windows? Is the Linux runtime engine capable of running the windows VI?


In short, what we like to do is: Use windows to develop some VI's with serial communication. Copy the VI's to a Linux system. Start the VI's.


Any ideas are greatly appreciated.


Wiebe.

[tst]

I don't know about the part of detecting an installed program or how to find the VI, but I can answer about running the code - it won't work.

When you save a VI in LV the compiled machine code is saved as part of it (that's why you get the VI Recompiled message in the changes dialog when opening a VI in a newer LV version). The RTE actually runs this compiled code and since Linux cannot run Windows binary executables it won't work unless you open it first in LV for Linux and save it there.

One other option I can think of is using Windows emulators like Wine, but I have no idea if that will work. Rolf can probably answer that better (and he probably has already, just search for it).

[Wiebe@CARYA]

"tst" <x@no.email> wrote in message news:1171021210437-475839@exchange.ni.com...
I don't know about the part of detecting an installed program or how to find the VI, but I can answer about running the code - it won't work.
When you save a VI in LV the compiled machine&nbsp;code is saved as part of it (that's why you&nbsp;get the VI Recompiled message&nbsp;in the changes dialog when opening&nbsp;a VI&nbsp;in a newer LV&nbsp;version). The RTE actually runs this compiled code and since Linux cannot run Windows binary executables it won't work unless you open it first in LV for Linux and save it there.
Like you said, Linux isn't executing the VI's, the runtime engine is. And the assembler code inside the VI is probably not OS specific, but only processor specific. Thread handling code and such are most likely not handled in the VI's binary code, but by calling RTE routines. This will be done very similar on Windows and Linux. So I think theoretically it is possible to do this without problems. But you are probably right that it doesn't work, since LabVIEW checks a version bit and simply returns an error.




One other option I can think of is using Windows emulators like Wine, but I have no idea if that will work. Rolf can probably answer that better (and he probably has already, just search for it).


Having to install Linux and LabVIEW to get a VI running under a Linux runtime engine is only inconvenient, but no problem.


But we can't get a Linux LabVIEW version with application builder soon, and we can't put a development version on every application system. So we have to get VI's running with the RTE, without building an executable.


Thanks for the quick respons.


Wiebe.

[shoneill]

The compiled code is apparently (according to Rolf, he informed me on this topic about a year ago) proper machine code which is indeed OS dependent.

I was, up to that point, of the opinion that only non-compiled code was saved in a VI, and that it was truly portable (as would be useful I reckon).   But apparently, the compiled code is what is executed.  It is NOT re-compiled when run, thus you need to save a VI for linux on a linux machine, a windows VI on a windows machine and so on.

Personally, I'd prefer a "portable" solution.

Either way, would a virtual PC be a viable solution (for saving in different versions I mean)?

Shane

Message Edited by shoneill on 02-09-2007 01:59 PM

[tst]

---

@shoneill wrote:

Personally, I'd prefer a "portable" solution.

---

I don't know how large\complex the code that does the compiling is, but that would make the RTE even bigger than it is now {keep in mind that the code that LV has has to handle opening VIs from older versions, implementing changes, etc.).
Also, I'm guessing it's not in NI's interest to allow people to be able to compile code without paying for the IDE.
Another problem is that if the compiled code was not saved as part of the VI all of the VIs would have to be compiled each time you ran them and that would make the performance very bad. The other option is not to have the code compiled at all, just interpeted (LV 1 actually had this), but that is also a recipe for bad performance.

One possible option is having a virtual machine (like Java), so that you only have to write a VM for each OS, but I have no idea what that means from a technical standpoint.

[shoneill]

I was also thinking along the lines of a VM approach.  I did briefly think about saving compiled versions for Windows, Linux and Mac in one VI (kind of a kludged portability I reckon) but I hadn't figured in RT at all (or PDA...).  Of course there it would seem overkill to add several compiled versions, even if it was possible.

I think a VM apprach would add a lot of functionality, but at what cost?  I think going back to interpreted code is a BaAaAad idea (in my best sheep-voice).

It just seems wierd not to be able to offer a VI as a plug-in (to be called dynamically from an application) without having to specify which OS it's for.......

"Also, I'm guessing it's not in NI's interest to allow people to be able to compile code without paying for the IDE. "

I have to agree on that one.

Oh well.

Shane.

[Wiebe@CARYA]

"shoneill" <x@no.email> wrote in message news:1171026608228-475874@exchange.ni.com...
The compiled code is apparently (according to Rolf, he informed me on this topic about a year ago) proper machine code which is indeed OS dependent.I was, up to that point, of the opinion that only non-compiled code was saved in a VI, and that it was truly portable (as would be useful I reckon).&nbsp;&nbsp; But apparently, the compiled code is what is executed.&nbsp; It is NOT re-compiled when run, thus you need to save a VI for linux on a linux machine, a windows VI on a windows machine and so on.Personally, I'd prefer a "portable" solution.Either way, would a virtual PC be a viable solution (for saving in different versions I mean)?ShaneMessage Edited by shoneill on 02-09-2007 01:59 PM


Well, if the binary code is OS independent, there is no need to re-compile at all! The windows VI should be able to run on a Linux runtime engine... My guess is that there is some OS check that prevents this.


Anyway...


Using a VMWare VM is a solution we are working with. Indeed, this probably solves the version problem of running the VI.


But I still can't find a way to start a vi with the rte. I simply do not know what to start! In windows, typing the vi's name on the command line starts the vi in the runtime engine. Linux doesn't work like that.


I still can't confirm that the runtime engine is able to run VI's under Linux. I know is *should* be able to do this, but is it? And how is it done?


Regards,


Wiebe.

[Wiebe@CARYA]

"shoneill" <x@no.email> wrote in message news:1171028409387-475890@exchange.ni.com...
I was also thinking along the lines of a VM approach.&nbsp; I did briefly think about saving compiled versions for Windows, Linux and Mac in one VI (kind of a kludged portability I reckon) but I hadn't figured in RT at all (or PDA...).&nbsp; Of course there it would seem overkill to add several compiled versions, even if it was possible. I think a VM apprach would add a lot of functionality, but at what cost?&nbsp; I think going back to interpreted code is a BaAaAad idea (in my best sheep-voice).It just seems wierd not to be able to offer a VI as a plug-in (to be called dynamically from an application) without having to specify which OS it's for......." Also,&nbsp;I'm guessing it's not in NI's interest to allow people to be able to compile code without paying for the IDE. "I have to agree on that one.Oh well.Shane.



But it *is* in Nil's best interest....


A Linux user can never try out a vendor's VI with the run time engine if the VI is made on windows!


Or vendor's would have to provide a LabVIEW application for each version of LabVIEW and for each operating system?!


Also, if this was there philosophy, why provide a separate runtime engine at all? They might as well force everyone to buy the application builder.


Linux (or OS independency) used to be one of the selling points of LabVIEW. No that Linux is getting bigger and bigger, the effort to support it seems to get less and less.



I'm Still hoping someone can confirm a Linux VI can run on Linux with only the runtime engine (and tells me how). But a nice discussion just before the weekend is fun too.



Regards,


Wiebe.

[shoneill]

Wiebe,

I wrote that the binary code is OS dependent, not independent.  Please re-check my post (and your reference to my post to rule out cheeky editing.... 😉 )

Regarding running a linux VI on linux without the development environment, I wouldn't know since I've never used LV on linux (yet).  I thought the original duscussion was about running a VI from one platform on another without requiring the development environment to re-compile.  Can't you just build a wrapper VI to call the VI from a built application (provide path and hey presto, it can be called dynamincally.....no?)

I also agree that a bit more multi-platform support would ultimately help NI, but I can understand the thinking behind it.  Not that I agree, I just understand 😉

Further, I believe the run-time is required to prevent each and every LV application being huge.  But sometimes I wish we could distribute without theis run-time Stigma (or better - have the choice).

You've raised an interesting point by questioning the existance of the run-time engine......

Shane.

Message Edited by shoneill on 02-09-2007 04:01 PM

[Wiebe@CARYA]

"shoneill" <x@no.email> wrote in message news:1171033813849-475970@exchange.ni.com...
Wiebe,I wrote that the binary code is OS dependent, not independent.&nbsp; Please re-check my post (and your reference to my post to rule out cheeky editing.... 😉 )Regarding running a linux VI on linux without the development


You're right. Let's blame it on the language barier (on my side), and today being fryday. Still I don't see why assembler code can't be the same on two exactly the same i386 processors. The OS stuff should be handled in the runtime engine, and the add's mul's, call's etc. are the same. But I haven't given in much thought, and never tried anything like that. I'm sure their will be some problems.


environment, I wouldn't know since I've never used LV on linux (yet).&nbsp; I thought the original duscussion was about running a VI from one platform on another without requiring the development environment to re-compile.&nbsp;


It was about running a VI on Linux with only the rte. And what's needed to make this happen.


Can't you just build a wrapper VI to call the VI from a built application (provide path and hey presto, it can be called dynamincally.....no?)I also agree that a bit more multi-platform support would ultimately help NI, but I can understand


Yes, if we had an application builder for Linux, we could make a wrapper. It would solve the licensing problem. Perhaps someone can make a Linux application wrapper/vi starter for LV8.2 (we'd be happy with any version though)?


About the support.. Somehow someone forget to put all the Linux documentation on ni.com.


the thinking behind it.&nbsp; Not that I agree, I just understand ;)Further, I believe the run-time is required to prevent each and every LV application being huge.&nbsp; But sometimes I wish we could distribute without theis run-time Stigma (or better - have the choice).You've raised an interesting point by questioning the existance of the run-time engine......Shane.Message Edited by shoneill on 02-09-2007 04:01 PM



Someone ought to make a virtual machine that can execute LabVIEW's executable code inside a vi, and simulate the runtime engine at the same time : ) It will take some time though...


Regards, Wiebe.