Error -18004 with LabVIEW Adapter using LabVIEW Run Time Engine 7.1.1

Hi to all,
I am trying to use the LabVIEW Run Time Engine 7.1.1 instead of the Development System for executing VIs in TestStand with the LabVIEW adapter.
The Problem is that I get the following error, saying that my VIs cannot be executed:
-18004; An error occurred accessing the LabVIEW Run-Time Engine DLL.
All my VIs were masscompiled with LabVIEW 7.1.1
How do I manage this problem, in other words how do I get my VIs in TestStand to run with the LV Run Time Engine?
Thanks for you help,
- Caribe -
PS: I configured the adapter to use the LabVIEW Run Time Engine 7.1.1. When I check back in the dialog "LabVIEW Adapter Configuration" the selector went back to LV Runtime 7.1??? Thats weird dude!

Hi Caribe,
Did you find any solution to this weird behaviour? Even I am facing the same problem! If we set the adapter as LV 7.1.1 runtime engine, it changes back to LV 7.1 runtime engine.
I am also facing -18002 error after mass compiling LV 7.1 folder and my source code folder.
If you can share your solution, that would be of great help to me. If i couldnt find any solution, I have planned to revert back to LV 7.1 version.
Thank you,
Sasi

Similar Messages

Why does my LabVIEW 2010 Program ask for the LabVIEW 8.5.1 run-time engine every time it is launched after being installed?

It is a simple timer program that shows the elapsed time (see attached pics). I can't think of a single thing that should be causing this ... It started happening right after I selected scale objects with front panel resizes and recompiled, and re-installed the app. It was not happening before that when installed without the selection of resizing, but then I removed the selection and it still happens. Any Ideas would be appreciated.
Solved!
Go to Solution.
Attachments:
Timer Block Diagram.JPG ‏100 KB
Timer Front Panel.JPG ‏34 KB

A bit more info:
If I cancel through all of the dialog boxes (see attached) when trying to launch my little app, it runs normally. Looks like it really doesn't need the 8.5.1 engine after all.
Attachments:
Run-time Engine 8.5.1 dialog box.JPG ‏25 KB
Run-time Engine 8.5.1 dialog box - 1.JPG ‏15 KB

Test Stand LabView adapter 8.6 run time will not run 8.5 VIs

I’m trying to run a script I developed with a dev computer on
a regular PC set up with a Test Stand User Gui, and run times for Test Stand
and Labview.
With the Test Stand Labview adapter set to 8.6.1 all of my
ENA(Agilent Network Analyzer) calls fail for “VI Version is too early to
convert to the current LabVIEW version.” The ENA library is written in 8.5. If I set the adapter to 8.5.1 then all of the
VIs developed in 8.6 fail. In addition
it will not run any VIs that I save back to 8.5. I installed a demo Labview development
version (2010?) and everything ran fine with the adapter set to Development
System.
I am not sure what to try next to get it to run on the
regular PC, any hints.
Test Stand = 4.2
LabView = 8.6
Running in windows XP
Solved!
Go to Solution.

One of the many things I tried was saving the ENA library to 8.6, but I could not get it work.
This is the Original library I installed and was trying to Convert (8.0 upgrade agena.zip)
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=001CE83736F3674BE0440003BA7CCD...
I am about to try this one. (8.2.1 Upgrade)
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=74D1F1D4EB5268E8E04400144FB7D2...
I am pretty new to labview so I am not sure how to make the save to previous version workfor libraries, but I can easily do it with individual VIs. For libraries, it creates a new directory, and puts in all of the files and then asks me about saving the lib files as something else. This is where I think I get it wrong. I tried it again today and got the same results.
I greatly appreciate the Help
Brian

Why is VI not executable using Labview 7.1 Run-Time Engine?

Hi,
In our Teststand sequence, we have a Labview Action step which is returning an error: "The VI is not executable", along with the error code: -18002.
This error occurs on a Production PC using the L.V. 7.1 Run-Time Engine.
I'm aware of Mass Compiling to ensure all the VI's are the correct version, but this has not resolved the problem.
The software was installed on the production PC using a Teststand created installer, with the Labview Adapter set
correctly to the Run-Time Engine, i.e. not trying to open the Labview Developer Server to execute the step at run time.
Because it's the 1st Labview module to be executed, I added another similar step to run beforehand, i.e. the new simple
Labview code ran first. This executed correctly, but then the next step caused the error above.
The small number of associated sub-vi's are on the target PC, and have been mass compiled.
I've had -18002 errors before, but this is one I cannot cure.
All suggestions gratefully received.
Gary.

Hi Guys,
Regarding this -18002 error when using the Run Time Engine instead of the Development Environment, what is the VI within the step that is failing (in any of the cases you've mentioned) trying to do? Are they built around any toolkits?
In my experiments with a simple VI (with just a user dialogue) using the LabVIEW 7.1 RTE in both TestStand 3.1 and 3.5 this morning, I haven't found any issues
There is a possibility if any of the sub-VIs or toolkits you use contain a Merge Errors.vi, that the Run Time Engine picks up a copy of the VI built for previous versions of the RunTime Engine (due to the order in which the sub-VI directories are scanned), and it cannot convert it.
There are a few solutions for this, the easiest one looks to be to copy the error.llb\Merge Errors.vi for LabVIEW 7.1 into the same directory as the VI you're calling (so TestStand can pick it up easily).
Can you let me know if this solution helps at all? If not, would it be possible to post up any of the code or sequence you're having problems with?
Best wishes,
Mark
Applications Engineer
National Instruments

Installer Error of LabView Run Time Engine 6.0.2 "premature"

I cannot Install the LabView Run Time Engine on a Computer which runs on Windows 2000.
The Installation breaks on start with the Error Message: "Installation ended premature, because of an Error!"
Does anyone know what to do is ?
Thanks for Help

It's rather difficult to guess why since the error does not give any more information, but there are a few things you can try. First, if you are installing from a CD, try downloading the installer to your desktop first and then run it. CD-ROMs can sometimes run slower that the installer and this can cause problems. Also, check to see what other NI software may have been installed on this machine and determine if any of it could conflict with the 6.0.2 Run-Time Engine. Just possibilities but hopefully they can get you going!
J.R. Allen

Can I use LabView Run-Time Engine on Windows XP?

An Application uses LV Run-Time Engine 5.1, i want to use this application on windows XP, can i use the same version of the RTE, if not, what is the solution??

To eleminate the possibility of errors, you need to convert the application to a version fully compatible with windows XP, like 6.1 or 7.0 (6.02 should do it)
Would version 5.1 work with XP, NI do not gaurantee that. However, I had installed apllications written in version 5.1.1 and worked fine under XP. In your case, just give a try, if it did not work as expected, you may have functuionality that may not be fully comptaible with XP.

Upgraded from LabVIEW 8 to 2013 and now VI asks to find the installation package for Run-Time Engine 7.0

I recently installed LabVIEW 2013 on a computer (running Windows XP 32-bit). The machine also has LabVIEW 8 installed, which is what I was using prior to upgrading. I opened a VI that was created in LV8 and then saved it and all its subVIs in LV2013. Now when I open the VI in LV2013 and try to run it, a window pops up asking me to find the "lvruntimeeng.msi" installation package for LabVIEW Run-Time Engine 7.0. If I cancel that dialog box and the subsequent message stating that the installion files were not found, the VI appears (at least from intial inspection) to run normally.
I closed LabVIEW, downloaded Run-Time Engine 7.0 from the NI website, and tried to install it, but I received a message saying that it is already installed (as I had suspected). How can I determine what part of the VI and/or its subVIs is trying to make use of Run-Time Engine 7.0? Alternatively, how can I get LabVIEW to instead use the Run-Time Engine 2013 that was installed when I upgraded to LabVIEW 2013?
Solved!
Go to Solution.

Bob_Schor wrote:
Are you running your VI from a Project? If so, you can look at Dependencies and get an idea what "dependent" VIs you might have. There may be "something old" in your LabVIEW 8 code that has been superceded in 2013, but still "hangs around" -- if you can identify it, you can probably replace it with its "more modern" equivalent.
If you do not have the VI in a Project, you can simply open LabVIEW, create a new blank project, and add your top level VI to it. If all of your relevant VIs are in a single folder, add the entire folder. Now look in Dependencies.
BS
Yes I am running the VI from within a LV Project. After some more searching in the NI Knowledgebase I was able to fix the problem by using the following procedure:
1. Use the Measurement and Automation Explorer to uninstall Run-Time Engine 7.0
2. Restart the PC
3. Open the project, close the project choosing to "save all"
4. Restart the PC
5. Re-install Run-Time Engine 7.0 using a file downloaded from ni.com
6. Restart the PC
7. Open the project, close the project choosing to "save all"
8. Open the project and run the VI. No more messages about LabVIEW trying to find Run-Time Engine 7.0.

Can't Uninstall Labview Run-Time engine 6.0

I've uninstalled Labview 6.0 however, Run-time engine is still listed under the Add/Remove wizard in windows. I've manually unistalled it successfully but, it reappears, even after reboot.
How do I uninstall it for good?
thanx,

J-Tek,
I would suggest re-installing the Run-time Engine and then uninstalling it after a reboot. Also, you can download a program called Msicuu.exe (for NT, 2000, XP or Msicu.exe for 9x) to help clean up the registry for uninstalled programs.
Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

Run-Time Engine error

I have created an automated test and had it running as an executable on a stand alone test computer. I updated my LabView software to 8.6.1. I just made some changes to the test and recompiled it. When I tried to run it on the stand alone computer it gave me an error about the LabVIEW 8.6.1 run-time engine missing. I thought when the project was built all the files that pertained to running it were also built into the folder. Has anyone run into this that could offer some advice.
Thanks
Chirs
Solved!
Go to Solution.

Did you create an installer or simply build the exe? If you only built the exe you will need to install the run-time engine on the target machine. If you created an installer you can include the installation of the run-time engine as part of the installer.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

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

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

What's the cost of Labwindows run time engine

Dear Sir,
I have some questions about CVI and hope you can help me figure it out as usual.
1st, what's the advantage of labwindows against Labview? I know one is C programing environment and the other graphical environment. But the Labview seems more user-friendly.
2nd, What is run-time engine according to your definition? I know Matlab has similar component and is free of charge. Does the run time engine in Labwindows charge? If so, how much?
3rd, Previously, I thought labwindows is used to convert Labview program into C source code which is faster (how fast, compared with labview) and very popular in the industries, so companies do not have to buy labview and run it for just simple application in the field. But if the run time engine costs a lot, I can find no reason to use labwindows.
Thank you very much!

1) LabVIEW is a graphical based programming environment and
LabWindows/CVI is a C based programming environment. Both can be used
for similar tasks. Users familiar with C may prefer CVI. LabVIEW is
typically easier to learn if you are unfamiliar with both.
2)
The Run-Time Engine is a separate component that can be installed to
execute LabWindows/CVI programs and LabVIEW programs. It is free of
charge for both LabVIEW and LabWindows/CVI.
3)
LabWindows/CVI does not convert any LabVIEW programs into C code.
LabVIEW programs are already compiled as you write them, so you won't
need to convert them to C to use them. You should see similar
performance in similar LabVIEW and CVI code.
Allen P.
NI

Run time engine compatibility

I want to install a executable developped with LabVIEW 2009 and its run-time engine on a PC with LabVIEW 7.1. The executable is used to control an instrument by GPIB. The project in LabVIEW 7.1 use a digital IO board (PCI-DIO-32HS) and also use the GPIB board.
I just want to make sure that installing the executable and LV2009 run-time engine will not cause any malfunction in the LabVIEW 7.1 VIs.
Thanks
Ben64

Should be no problem. LV 7.1 and 7.1.1 had some engine conflicts between them but I think you're safe with any 2009 executable. If 2009 corupts 7.1 I'm sure someone would have seen it by now.
Using LabVIEW: 7.1.1, 8.5.1 & 2013

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

Calling a VI which uses "system exec.vi" with LabVIEW run-time engine as adapter

Hi,
My TestStand sequence calls a VI which includes a call to "system exec.vi". When I try to load it in TestStand and if LabVIEW adapter is set to run-time engine, I get an error message "Unable to load Vi...". If I switch the adapter to "Development system", then it works fine.
Is there any way to use "system exec.vi" in a VI which is called in TestStand with LabVIEW run-time ?
Thanks,
Alex
Solved!
Go to Solution.

Hi Alex,
In you case, you are getting a -18002 error.
The reason is explained in the following link:
-18002 Errors in TestStand
http://digital.ni.com/public.nsf/allkb/D82FEAF0B4BA293A862575710053E252?OpenDocument
Please have a look at the 2nd reason. This is your case.
Hope it helps,
Regrads
Julien De Freitas / Applications Engineer / Certified LabVIEW Developer (CLD)
National Instruments Switzerland

Error -18004 with LabVIEW Adapter using LabVIEW Run Time Engine 7.1.1

Similar Messages

Maybe you are looking for