Distribution kit run time engine

Hi is it possible to create a distribution kit with a higher version RunTimeEngine than the one being used to create it? I would like to include cvi2009 rte with my distribution kit built using labwindows cvi 9.0..
Thanks!!

I'm not sure if the runtime engine installer by itself will install the merge modules. You can install CVI 2009's evaluation version, which will install the merge modules, but I don't know if that will work correctly in terms of creating a functional distribution from CVI 9.0. Perhaps someone from NI can comment?

Similar Messages

Include LabVIEW Run-Time Engine in C# Project Distribution

I have written a software package in Visual Studio using C# which calls a number of functions from a dll which I have built in LabVIEW. I am now trying to produce an installation program for my C# package but can't quite work out how to include the LabVIEW Run-Time Engine in this installation.
I am creating the installation program by defining a Visual Studio Deployment Project and I have added my LabVIEW dll to this. However, the dll requires the LabVIEW Run-Time Engine to also be installed on the target PC. I was hoping that there would be a set of files to implement the installation of the LabVIEW Run-Time Engine that I could include in my Visual Studio Deployment Project and do the installation of both my C# code and my LabVIEW dll (inc Engine) in one operation. Is this possible? Or do I need to produce a LabVIEW installation for my dll separately from the C# installation?
Info:
Development OS = Windows 2000
Target OS = Windows XP
C# Development Environment = Microsoft Visual Studio 2005 V8.0
LabVIEW Version = 8.5
Also, I am using the Order Analysis Toolkit and noticed that there seemed to be an 'Order Analysis Run-Time Engine' installed on my PC. Do I need this too?
Thanks for any help.
CAS

Hi CAS,
One way of automating the installation of the LabVIEW run-time engine is to use commands in a batch file (*.bat). These commands would be executed automatically at the same time as your distribution installer to install LVRT with your C# application. For more information on command line options, have a look at this KB. I don't have so much knowledge of C# distributions, though, so there may be a better way to approach this that someone else in the community could advise you on.
With regard to the order analysis toolkit, you will also need this runtime engine installed. A point to note, though, is that the toolkit requires a run-time licence to be deployed in this fashion. It is now part of the Sound and Vibration Measurement Suite and needs to be licenced accordingly.
I hope this helps!
Best regards,
Tom
Applications Engineering, NI UK

Executable not working - Looking for LabVIEW Run-Time Engine

This has been one of those days.
I'm trying to create my .exe file to place onto another computer. I've done this before with success. But that was then and this is now.
I believe I have all the files I need in my LLB, and I believe I did my application distribution correctly and I believe I built the DLL correctly. But when I took the resulting .exe file and placed it on another computer and attempted to run it, it gave me the error message: "Unable to locate LabVIEW Run-Time Engine. Program requires a version 7.1 (or compatible) LabVIEW Run-Time engine. You should have already realized this, you moron."
Anyone have any idea where I went wrong or what step I might have missed? This has been a crazy, non-stop, massive brain fart of a day and I can't seem to remember what I'm missing here.
Amateur programmer for over 10 years!

Hi.
Whenever you want to use executables or .dll's created with LabVIEW you must make sure that the LabVIEW runtime engine of the SAME version as the LabVIEW version used to create the files, is installed in the target computer.
There are basically 2 ways to get the run-time engine installed on a computer:
1. (the one I prefer): Download the correct version of the LabVIEW run-time engine installer from www.ni.com/downloads, or more specifically from
http://digital.ni.com/softlib.nsf/websearch/369618104E25B08E86256F54006A4E2F?opendocument&node=132050_US
for the latest one. Once you have the installer for the run-time engine, just install it in the target computer. I prefer this option because the run-time engine is installed independently, so if you then uninstall your program, the run-time engine remains.
2. Create an installer for your program that includes the run-time engine. To include the run-time engine, when you are creating your application, go to the "installer settings" tab, click on "Advanced" and make sure there is a checkmark on "include LabVIEW run-time engine". This way when you install your program in the target computer, the run-time engine will also be installed.
Just as a note, any computer with LabVIEW on it, will also have the run-time engine.
Good luck.
Alejandro

Call VI in EXE but have it execute in Development Environment not Run Time Engine

I am working on building a palette editor for distribution of a reusable code library for my company (I know the VIPM does this very well already). I have the code complete and am trying to create an executable that I can distribute that will call the code I wrote to update/create the palette .mnu files for the reuse library, which lives on the company network. I am using the Palette Editing VI's and it seems as though they cannot be built into an executable. So I wrote some code to dynamically call my palette modification code (I call it the Reuse Library Manager). When my executable calls the Reuse Library Manager dynamically I get a broken run arrow on the Reuse Library Manager front panel and the following reasons for the broken arrow:
It seems to me that the reason the Reuse Library Manager works when called in the development environment and not when called dynamically is because the dynamic call uses the run time engine for execution. This made me think of how in the VIPM it opens LabVIEW while it installs packages. If anyone knows, does the VIPM open LabVIEW in order to run the Palette Editing VI's or is it for another reason? If it is this reason how can I force the dynamically called VI's to run in the development environment by opening LabVIEW programmatically from an executable that is running in the run time engine?
Let me know where clarification is needed.
Message Edited by jmcbee on 04-28-2009 10:00 AM
CLA, CLED, CTD,CPI, LabVIEW Champion
Platinum Alliance Partner
Senior Engineer
Using LV 2013, 2012
Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.
Attachments:
Reuse.PNG ‏14 KB

Hi jmcbee,
In spite of years of using LV and building a resuable library of code, I've done very little with customizing the standard paletts, however,
Many times when deploying a new distributable I've seen a dialog like what you posted. In most cases the problem was solved by rebuilding distributable to include the missing VIs. In one case I added the VI-lib to the target-platform and made-sure VI-lib was in distributable's VI search-path.
There are two ways I know of to build distributables which include the VI-lib code,
1) Include all VI-lib VIs when building the distributable
- In LV 8x, uncheck "Exclude Files from VI lib" project-property.
- In LV 7.1 it's possible but I don't remember how! (probably a post on it around here.)
- This can add an enormous number of un-needed VIs (see this post.)
2) Re-write the VIs so that they are no-longer identified with VI-lib and get included "naturally".
- Open each VI diagram, select-all, paste in new/untitled diagram. In your case naming will be tricky, but it's doable.
- This is a great advantage in 8x as it allows LLBs to be built with File\Save As\Create Hierarchy.
In addition, here's a tool to call following "Open VI Reference" (if it returns an error.) This VI open all broken children making it much easier to identify specific missing parts (typically VI-lib.)
Luck/
Cheers!
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Attachments:
Util.VI.OpenBroken.vi ‏57 KB

How to prevent prompt to install CVI Run-Time Engine?

The LabVIEW laptop for my client got messed up, so I spent several hours making it forget everything it ever knew about NI software. I started by uninstalling all NI applications, then manually deleted all the folders that the uninstaller leaves behind, then ran a couple of registry cleaners to sweep out as much NI as possible, and finally ran regedit to see what was left. In the end there were only some legacy drivers that regedit would not let me delete.
Then I installed 8.6.1 from DVD, carefully selecting only the options we needed; LabVIEW core, cRIO, FPGA, PID, and the minimum set of drivers the installer would let me get away with. Note that no Labwindows/CVI option boxes were checked. When the installation was complete, I rebooted the machine and launched LabVIEW, which immediately prompted me to install the LabWindows/CVI 8.5.1 (not 8.6.1) Run-Time Engine. I dutifully fed it my 8.6.1 DVD, which caused LabVIEW to crash. After 3 reboot/retry cycles with the same result, I decided to appeal to the forum for help.
What is causing LabVIEW to think I need the CVI Run-Time Engine (and a down-rev version, at that), and how do I convince LabVIEW that I do not?
Jeff

Thanks for the reply! OK, so LabVIEW needs the CVI RTE even though I'm not using any CVI features. I can live with that. I downloaded LabWindows/CVI Run-Time Engine 8.5 from the NI web site and tried to install it. After I confirmed that I accepted whatever that license agreement says, the installer told me that "No software will be installed or removed."
Then I opened LabVIEW, and it went through the same "The feature you are trying to use..." popup and tried to install the CVI RTE. The installation failed as usual, and LabVIEW crashed.
A few minutes ago I found and ran CVTRTE.msi on the 8.6.1 distribution DVD. I selected the "repair" option, which completed successfully. After rebooting, I launched LabVIEW only to be greeted with the now-hated NI LabWindows/CVI 8.5.1 Run-Time Engine installer.
The part of this that is so infuriating is that there appears to be no way for anyone to make a computer forget everything NI so you can start with a clean slate.
Jeff
Attachments:
NoCanDo.jpg ‏28 KB

Call a VI whith the Run-Time Engine in TestStand

Hi,
I'm using TestStand 4.2.1. On the same PC I've installed LabVIEW Run-Time Engine 2009 (9), 2010, ...
On another PC I developped a series of VI with LabVIEW 2010. My client want VI in the 2009 version, that's why I use a Run-Time Engine.
I placed an action step, selected my VI and the adapter was not able to load the VI (as viewed in the attachment).
Before I had selected the right Run-Time Engine (in Configure -> Adapters), and I saved the VI in the 2009 version (instead of 2010).
What is the problem ?
Another problem is that in an other VI I use an XML library (the default in LabVIEW), How convert the entire library in the 2009 version ?
Thanks for your help
Attachments:
Erreur VI.png ‏975 KB

Hi,
One way to check if vi's are compiled in LV2009 is to select menu item 'View VI Hierarchy' from the top level vi. Then select 'View>Full VI Path in Label' and 'Always Show Labels'. Check that none of the VI's are in the LV2010 paths.
To fix, you may have to create a project (File>New Project from your top level VI - Add the VI to the project when prompted). Right click on the Build Specifications and create a new 'Source Distribution'. Check that under 'Additional Exclusions' that VI's in vi.lib, user.lib, and instr.lub are not excluded. This should package up all of the VI's into a library that will run in the LV2009 RTE.
Thanks,
Jim

You may not need to install the Run Time Engine...

I know this has been mentioned before, but after a long search of the archives, I couldn't find the right person to give credit to - sorry!
If you have a simple exe, you may not need to install the runtime engine on the target machine at all - all you need to do is include some of the engine's files with the exe for it to work. Try it out: copy the following files & folders into the folder containing your exe:
..\National Instruments\shared\nicontdt.dll
..\National Instruments\shared\nicont.dll
..\National Instruments\shared\LabVIEW Run-Time\your_version\everything (including all sub-directories)
so, using 6.1 as an example, you exe's directory would like something like:
..\AppDirectory\MyApp.exe
..\AppDirectory\MyApp.ini
..\AppDirectory\My_Apps_DLLs,if_any
..\AppDirectory\nicontdt.dll
..\AppDirectory\nicont.dll
..\AppDirectory\lvapp.rsc
..\AppDirectory\lvjpeg.dll
..\AppDirectory\lvpng.dll
..\AppDirectory\lvrt.dll
..\AppDirectory\mesa.dll
..\AppDirectory\serpdrv
..\AppDirectory\models\heaps_of_stuff_in_here
..\AppDirectory\errors\more_stuff_in_here
..\AppDirectory\script\and_some_bits_in_here_too
Take all of this data to a machine without LabVIEW or the runtime installed, and try to run the exe - all going well, it will execute without any problems. This exe distribution method can be really useful, especially when distributing autorun presentations on CD-ROMs.
* DISCLAIMER: as far as I am aware, this method is NOT authorised or supported by NI - use it at your own risk!
cheers,
Christopher
PS: I'd like your feedback: please give this posting a rating
Christopher G. Relf
[email protected]
Int'l Voicemail & Fax: +61 2 8080 8132
Aust Voicemail & Fax: (02) 8080 8132
EULA
1) This is a private email, and although the views expressed within it may not be purely my own, unless specifically referenced I do not suggest they are necessarily associated with anyone else including, but
not limited to, my employer(s).
2) This email has NOT been scanned for virii - attached file(s), if any, are provided as is. By copying, detaching and/or opening attached files, you agree to indemnify the sender of such responsibility.
3) Because e-mail can be altered electronically, the integrity of this communication cannot be guaranteed.
Copyright © 2004-2015 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.

Yes, this method is not supported. However, this method is good if you wish to write your own installer for a LabVIEW Application. (Note: The method above does not install DataSocket, NI-Reports, or any of the 3D Graph controls.)
I would still suggest running the LabVIEW Run-time Engine installer so that more than one application can use it.
Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

How to specify a different directory for the Run-Time Engine?

With LV 7.1 it's become even more difficult to create installation sets in third-party tools without having to include the full run-time engine separately.
If you use any of the advanced analysis VIs you have to install the run-time engine (no use in including files in the same directory as the built application) and if you do and you use the old serial VIs you get a problem because the application will load the run-time from the main run-time installation and then look for serpdrv in that directory, not in the application folder...
So - being forced to use the installer builder in the application builder and include the run-time engine in the installation kit I wonder whether it is possible to specify where the run-time should be installed?
By default it will go in a directory called National Instruments in the program files folder, however that is not ideal due to the fact that the users have no relation to the fact that our application needs something from NI...and may end up deleting the directory ("National Instruments? - what do I need that for...let me delete it...). We would like to be able to specify that the run-time is installed silently in a directory named with our company name instead.
MTO

When you create the stand alone, in options you can actually set the temp directory and default directory. You can change it there OR in goto options and check for libraries/directories. You can change it there too.
Kudos always welcome for helpful posts

Run time engine and NI-DAQmx installation order

Greetings Fellow Developers:
I'm looking at a product manual that contains instructions to install NI-DAQmx, a product software installer created with LabVIEW 2009 SP1 Full and then the LabVIEW 2009 Run Time Engine in that order.
This does not seem correct--particularly if a LabVIEW 8 (or previous) Run Time Engine is already installed.
Since I need to test installation of my builds before distribution I'll need to install them on machines that have never had any NI products and also on machines that may have previous Run Time Engines.
I feel the correct order is to install the Run Time Engine, NI-DAQmx and THEN the application. Prior to running the application the USB device should be plugged in so the 'add hardware wizard' can install the USB driver(s).
What is the consensus on this?
Warm Regards,
Saturn
Solved!
Go to Solution.

Hello Saturn,
Could you point out the location of the product manual that explains this order? Typically, when installing National Instruments products, in particular LabVIEW, we recommend installing LabVIEW, drivers, and toolkits in that order. So, installing the LabVIEW 2009 Run-Time Engine, DAQmx, and then your application should be the proper installation process.
Regards,
Roman Sandoval | National Instruments | RF Systems Engineer

Labview 6.0 run-time engine will not control BKPrecision power supply.

I created a test program in Labview 6.0 to control a BKPrecision power supply and Measurement computing DAQ in our test system. I am able to control both intsruments from my PC which has Labview loaded on it. I created an executable from the application builder tool for distribution. When i install the run-time engine and executable on a new PC (Labview not installed), i am unable to control the BKPrecision power supply. The BK power supply is connected to the serial COM port of the PC.
Do i need to install drivers that are not included in the executable build?
Do i need to install VXIpnp (VISA interactive control)?
thanks,
Tim
Solved!
Go to Solution.

tmann-
The API Drivers are often times for more specific Operating Systems than the others (Linux, Pharlap, etc.) and they are more easily accessible for programmers that want to (and have enough time to put up with the headaches ) of building speciality drivers off of ours. 99% of the time you just want the drivers that come up first when you type in your driver name (NI-VISA). As to versions, issues can crop up later from not using the exact same driver version but all the drivers are built off of each other (they hardly ever scrap an entire driver and start over) so the problems should be minor. Its up to you about switching. Unfortunately to downgrade version you have to completely uninstall the driver from Add/Remove Programs>>National Instruments Software>>Your driver and then reinstall the correct one. If you have time, I think it is well worth it to do it right the first time. Hope this is helpful!!
Grant H.
National Instruments
LabVIEW Product Marketing Manager

Does Vision Development Module obviate the need for the Vision Run Time Engine?

I have several computers with the full version of Labview (8.0.1 and\or 8.2) as well as the most recent version of the Vision Development Module (VDM 8.2.1), all fully registered and activated. In addition, I have one computer we have designated the "build" computer which has the professional version of LV 8.2 as well as LV 8.0.1 Full version w/ Application Builder (we have delayed migrating certain applications to 8.2 for various reasons). Instead of distributing applications as source distributions to these computers (uncompiled VIs), we would like to use our build computer to compile applications that make use of the Vision image processing VIs. I know that all of these computers have the appropriate LV run time engines installed, but I was wondering if I need to install (and thus purchase) the Vision Run Time Engine for each of these computers. I know that when you install VDM, you also get a copy of the vision RTE (in C:\Program Files\National Instruments\Vision\Run-Time Engine). Does this mean the engine is already installed and ready to run compiled applications? Or do we need to pay for the engine on each computer?

The Development module includes the RTE for that machine.
For the other machines, you will need to purchase the Vision RTE and install and activate for each machine. See the KB article below for more details.
http://digital.ni.com/public.nsf/websearch/F1699570F78FECBB86256B5200665134?OpenDocument
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

Path where to install the run time engine (on Linux)

I have a cluster of Linux computers where I would like to run compiled LABview (8.20 at the moment) applications build
with the application builder.
Therefore I would like to install the LABview run time engine on a NFS mount file system seen from each computer. But
the installation procedure of the run time engine does not propose to
choise the installation directory, but force the installation
in /usr/local/lib.
I try to workaround this problem and have copied the /usr/local/lib/LABview.8.2 directory to my NFS filesystem and
made the 'necessary' links.
Unfortunatly it doesn't run and fails because the
liblvrt.so.8.2 library can not access patched versions of the
libOSMesa.so.4
and libGL.so.1 librairies but uses the standard ones in /usr/X11R6/lib.
Even by setting my LD_LIBRARY_PATH correctly to access the patched librairies versions it does not run because the
liblvrt8.2 library seems to be linked with the following
'rpath' (given by the command 'strings liblvrt.so.8.2 |
grep patchlib')
$ORIGIN/LabVIEW-8.2/patchlib:$ORIGIN/patchlib:/usr/X11R6/lib:/usr/lib:$ORIGIN:$ORIGIN/LabVIEW-8.2/linux:$ORIGIN/linux:$ORIGIN/resource
which prevents to access the patched librairies versions if the $ORIGIN is not set. Therefore I tried to set $ORIGIN as an
environment variable but it doesn't change anything.
Therefore my question is: Did somebody have already had this type of problem, what is $ORIGIN and how I can set it ?
Thanks in advance.

Sir,
Please could tell me the distribution you use ?
Cordially,
Pierre R...
Certified LabVIEW Developer

Why do different versions of the LabVIEW Run-Time Engine not compatible?

LabVIEW Run-Time Engine to become more and more big
Why do different versions of the LabVIEW Run-Time Engine not compatible?
" 一天到晚游泳的鱼"
[email protected]
我的个人网站：LabVIEW——北方客栈 http://www.labview365.com
欢迎加入《LabVIEW编程思想》组——http://decibel.ni.com/content/groups/thinking-in-labview
Solved!
Go to Solution.

jwdz wrote:
LabVIEW2020 ....... ，it look like?
You need to express your ideas more clearly. We cannot fill in the blanks and read between the lines if the post has no substance.
jwdz wrote:
It will affect the future development of LabVIEW, right?
What is "it"?
There are many things that affect the future development of LabVIEW, starting with NI management, all the smart people in LabVIEW development, the economy, the LabVIEW users, etc.
If you are worried about the increasing size of the distribution, the good news is that the cost of data storage and data transmission has dropped much more dramatically. Even though newer versions are bigger due to great and welcome new features, the improvements in infrastructure have actually made the distribution and storage significantly easier over the years and will continue to do so. Trust me!
Nobody wants to go back to a LabVIEW version that fits on a floppy disk!
LabVIEW Champion . Do more with less code and in less time .

LabWindows/CVI 2009 Run-Time Engine update

I wanted to let everyone know that NI has released an udpated CVI 2009 Run-Time Engine. Information on what bug(s) this update fixes can be found here. If you are currently not using the CVI 2009 Run-Time Engine, you do not need to install this update.
This is an updated installation of the CVI Run-Time Engine, not a patch. If you download and install this update it will upgrade whichever version of the CVI Run-Time Engine you currently have to version 9.1.0.428 (CVI 2009 released with version 9.1.0.427). One way to find out which version of the CVI Run-Time Engine you have installed is to view the version number of c:\windows\system32\cvirte.dll. If you install version 9.1.0.428, any installer distributions that you create from any version of the CVI ADE will include version 9.1.0.428.
If you have not yet installed LabWindows/CVI 2009, it's recommended that you install this update, either before or after you install CVI 2009.
Luis

To be clear, the original problem that you reported ("Attempt to free pointer to memory not allocated by malloc() or calloc()") might very have been the problem that this patch fixed, which was in fact new to 2009. But that problem only happens if there were actual plots in the graph.
However, after looking at the "dynamic memory is corrupt" isse some more, it turns out that it is actually expected behavior, believe it or not. This is a limitation of easytab controls, caused by how they use callback chaining in their implementation. Whenever a panel or a control has its callback chained, you cannot change the callback, or make a copy of it after the chaining takes place. This is described in the EasyTab_ConvertFromCanvas function help ("...For the same reasons, do not call DuplicatePanel or DuplicateCtrl on any of these panels or controls after the Easy Tab control has been created.").
As you probably have read elsewhere, easytab controls are quite obsolete. They were a stopgap "solution" to the problem of there not being a native tab control in the CVI user interface library. Native tab controls were finally added in CVI 8.0, and so we recommend that, if possible, users update their code to use these instead.
Luis

Error involving Report Generation Toolkit and Labview Run Time Engine

Developed an application using LabVIEW 6.1 and LabVIEW Report Generation Toolkit for Microsoft Office 1.0.1. From there, tried to build a shared application for use with the LabVIEW Run Time Engine. The Run Time version functions properly until "New Report.vi" is called and then an error is generated, code 7, calling out "Open VI Reference in New Report.vi" could not be found. When building the application, I did include the "NI Reports Support" in the advanced installer options. The machine used for original development and application build is running Windows XP Pro and Office XP. Any suggestions??

I am having the exact same problem but with LV 6.1 and M/S WORD 2000. It appears that the "New Report.vi" is trying to open "C:\APP.DIR\Word_Open.vi" and "C:\APP.Dir\Word_Open_Document.vi" by reference. The "OFFICE 2000.TXT" says that "_exclsub.llb and _wordsub.llb must be added as support files when building an application or a dynamic link library with the application builder." I added them as Support Files and I copied them to the "C:\TESTER\" where the TESTER.EXE is and I still get ERROR 7 in "NEW REPORT.VI" at VI OPEN REFERENCE.
Do I need to make a "C:\TESTER\DATA\" sub-dir and put the support files there?
I am building on MY COMPUTER on F: Drive on a network and transporting files to the real Tester.
I displayed my App.Property of APP.DI
R at start up and it is C:\TESTER\ ! How would my application know that "Word_Open.vi" and "Word_Open_Document.vi" are actually inside the _wordsub.llb?
Any ideas ?
Greg Klocek

Distribution kit run time engine

Similar Messages

Maybe you are looking for