necessity of a run time engine

[Veena]

Can anyone tell me whats the detailed concept behind the necessity of installing the labview run time engine along with a labview application to make it work?
veena.

[Mads]

From info-labview:

http://messages.info-labview.org/2000/08/22/01.html

Other good answers are e.g.:

http://messages.info-labview.org/2000/07/14/11.html

http://messages.info-labview.org/2000/07/14/13.html

[mikeporter]

The idea behind having a seperate runtime engine is to reduce the size of the built application. The end result is that every LV-based executable on the computer can share certain code that they need in common.

However, even if you only have a single executable on the machine, having a seperate runtime engine can significantly reduce the amount of time to upgrade or otherwise maintain the code on the computer as the only time the runtime engine has to be reinstalled is if the version of LV changes--like from 6.0 to 6.1. That's why in the app builder there's a configuration strap that tell LV to not include the runtime engine in the build.

Are there specific questions/issues that you had?

Mike...

[Veena]

What i wanted to know was what does a run time engine exactly does and whats its necessity? I havent explored the versions compatibility parts...am new to labview and exploring various things theoretically and practically, since I cant find a particular place or book that gives a overall view, and theres only manuals available for now...
Veena

[agoff7]

"Veena" wrote in message
news:506500000005000000ECEB0000-1042324653000@exchange.ni.com...
> What i wanted to know was what does a run time engine exactly does and
> whats its necessity? I havent explored the versions compatibility
> parts...am new to labview and exploring various things theoretically
> and practically, since I cant find a particular place or book that
> gives a overall view, and theres only manuals available for now...
> Veena

I'm taking a guess here, Labview is an interpreted language and that means
it needs something to convert the labview code into machine instructions,
the converter is the Labview runtime engine.

I think even if you create a *.exe file you need the runtime engine to run
it. I don't have the full d
evelopment version though so don't quote me on
that.

If you look in the help index for run-time engine you will find this answer

"Using the LabVIEW Run-Time Engine
If you create a system using LabVIEW that runs applications or shared
libraries, then you must install the LabVIEW Run-Time Engine. The LabVIEW
Run-Time Engine includes the libraries and other files necessary to execute
LabVIEW-built applications and shared libraries. All client computers
running LabVIEW-built applications and shared libraries must also have the
LabVIEW Run-Time Engine installed.

The LabVIEW Run-Time Engine also includes a browser plug-in that allows
clients to view and control VI front panels remotely using a browser.

All applications and shared libraries built with a particular version of
LabVIEW will share the same LabVIEW Run-Time Engine installation, so only
one installation is required. If you use applications or shared libraries
that you create with different versions of LabVIEW (for example, 5.1,
6.0,
and so on), you must have the Run-Time Engine for each version of LabVIEW
installed on the system.

You can find an installer for the LabVIEW Run-Time Engine on your LabVIEW
CD. "

[Greg_McKaskle2]

>
> I'm taking a guess here, Labview is an interpreted language and that means
> it needs something to convert the labview code into machine instructions,
> the converter is the Labview runtime engine.
>

Just to clarify, LabVIEW is not an interpreted language. The conversion
of LabVIEW diagrams into machine code is compiling since it happens when
you push the run button or when you build an EXE. If it happened as the
diagram executed, then it would be interpretted.

The other posts contain more info, but the short answer is that the
runtime engine is similar to MFCRT.dll or the Java runtime. It is the
libarary of the most common functions that most executables need to execute.

Greg McKaskle

[crelf]

If you software fits into a narrow case of not needing certain components, you might get away without installing the RTE:

< http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000FB4D0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0 >

[Mads]

We have never installed the run-time engine using the installation set from NI. We want the customers to only run *our* installation sets, displaying *relevant* information and logos. Nothing saying anything about LV, NI, VISA, NIDAQ or anything else about the development tools used to make the software or the drivers that has to be included. It would be nice if NI made their involvement hidden by default. Due to licensing etc. this might not be possible in all cases, but it should be a goal to make it as transparent as possible, that does not seem to be the case now.

If you checked the include RTE, VISA etc. in the application builder it should just include it in the same installation kit and add absolutely no splash screens etc. In addition there should be
a solution to easily include it in installations built with other third party tools, as the one included in the application builder of LV6 is way too limited.

Anyway - The main files in the RTE is the lvapp.rsc and lvrt.dll (LV 6.1). In many cases making sure the app has access to those two files is all that is needed. If you display any pictures in the app - add lvpng.dll and lvjpeg.dll. If you use any of the new 3D control/indicators include the mesa.dll and the relevant model files in the models directory (see: http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/556a1641695250f486256b3700792105?OpenDocument)...if you use the serial IO VIs (not VISA) include serpdrv..etc etc.

Not the most flexible solution but better looking than the alternative.

If you are looking for an alternative to the installation maker in the application builder download a free one from http://www.jrsoftware.org/

[Mads]

The address to the document about including mesa.dll got corrupted, here it again:

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/556a1641695250f486256b3700792105?OpenDocument

[agoff7]

"Greg McKaskle" wrote in message
news:3EAB1811.4070408@austin.rr.com...
> >
> > I'm taking a guess here, Labview is an interpreted language and that
means
> > it needs something to convert the labview code into machine
instructions,
> > the converter is the Labview runtime engine.
> >
>
> Just to clarify, LabVIEW is not an interpreted language. The conversion
> of LabVIEW diagrams into machine code is compiling since it happens when
> you push the run button or when you build an EXE. If it happened as the
> diagram executed, then it would be interpretted.
>
> The other posts contain more info, but the short answer is that the
> runtime engine is similar to MFCRT.dll or the Java runtime. It is the
> libar
ary of the most common functions that most executables need to
execute.
>
> Greg McKaskle
>

So a vi gets compiled everytime it is run, unless it is an exe, then it gets
compiled once?