Installshield Merge Module Rather Than Run-Time Engine

I create installations for our company using Installshield 11
Professional. At this point, the only way to install the
necessary files to run a Lab View application is to add the Lab View
7.1 run time engine into the setup.
What I am looking for is an alternative. I am hoping there is
some sort of merge module out there which can be added to Installshield
so I don't have to call the Lab View run-time engine installer from my
installer.
Does such a thing exist?
Or does anyone have any advice on how I can make a Lab View installer using InstallShield and make the installation unified?
I don't prefer the current setup I have where our software installation
begins, then the run-time engine installer takes over, and then our
setup continues.
Thanks for any help,
Adam

jacko wrote:
Hi Rolf,
It seems to me that you are explaining the problem I encountered after finding the merge modules which Chris led me to. That problem was which merge modules to use?
I have in fact been trying to identify which modules I'd need, and was
going to do it by trial and error. If there is an easier way then
I'll give your method a shot.
Is this what you are refering to in your message above?
Well,
I'm not sure I understand you correct, but yes I think that is what my
message meant. Basically if you look at the two VIs and try them out
you will more or less see how they work.
You can then try to create a small tool, that given a *.msm file as
input will tell you which other msm files you need to include in your
Install Shield installer. If that is easier than trial and error is of
course something you can depate over. Also note that the order of
inclusion of msm files in an installer seems to be important too. The
lowest one in a depency chain should be first I believe.
For your particular problem you would look at the LVRunTime.msm
file to get a list of all other modules you need to include in your
installer. I actually would suspect that Install Shield should have
some functionality to list dependencies of merge modules, too.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

Error -17600 when switching from LabVIEW Development System to LabVIEW Run-Time Engine in Adapter Configuration

I receive an error message (code -17600) while loading my test sequence after switching from LabVIEW Development System (2009 f3) to LabVIEW Run-TIme Engine using the Adapter Configuration.
ErrorCode: -17600,
Failed to load a required step's associated module.
LabVIEW Run-Time Engine version 9.0.1f3.
When I switch back to the LV development system, everything is OK, and the sequence loads and runs perfectly.
My TestStand Engine Version is 2012 f1 (5.0.0.262).
I'd appreciate any help on this issue.
Roman

Hi Roman,
There are a couple of things you can try:
1) Determine if the LabVIEW RunTime Engine is corrupted in some way. Create a new simple VI with no sub-VIs, using the same LabVIEW Development system you used for mass-compiling the VIs. Create a TestStand step that calls this VI and ensure it runs correctly. Now switch your LabVIEW adapter to use the RuntimeEngine and choose the "Auto detect using VI version" option.
Check if the simple VI is loadable and runs without errors in TestStand.
If the step generates the same error, you should try a re-install of the LabVIEW development system.
If not, its most likely that there is some VI you are using that is not loadable in the LabVIEW Runtime Engine because:
1) Some sub-VI is still not saved in the right version or bitness. Open the VI heirarchy of the top-level VI that you are calling from TestStand and examine the paths of all the sub-VIs to check if they were in the folder you masscompiled and re-save any that are outside this directory.
Also, when you try to close the top level VI, do you get a prompt to save any unsaved files? If so, they could be the sub-VIs that are not saved in the right version. Save all of them.
Check if you are loading any VIs programatically and if these are compiled and saved in the right version as well.
2) There is some feature you are using in your LabVIEW code that is not supported in the LabVIEW RunTime Engine. To check this, add your top-level VI to a LabVIEW project and create a new build specification and create a new executable from this VI.
    Right-click "Build Specifications" and choose "New->Application(EXE)".
    In the Application Properties window, select Source Files and choose the top level VI as the start-up VI.
    Save the properties.
    Right-click on the newly created build specification and choose Build.
Run this executable (it will be run using the LabVIEW RunTime) and check if the VI has a broken arrow indicating that it cannot be loaded and run in the LabVIEW Runtime Engine.
You might need to examine your code and find the feature which is not supported in the LabVIEW RunTime and find an alternative.
Another thing i forgot to mention the last time around is if you are using 64-bit LabVIEW with 32-bit TestStand, then executing code using LabVIEW RTE from TestStand will not work since the 64-bit LabVIEW RTE dll cannot be loaded by the 32-bit TestStand process.
If none of the above steps resolve the issue, consider sharing your LabVIEW code so i can take a look.
Regards,
TRJ

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.

VISA Write differs between TS Development System and LV Run-Time Engine

Hi all
I made an application on LabVIEW to test BERs (Bit Error Rates), and I used VISA Write between two COM ports to exchange data.
Everything works fine using just LabVIEW.
Afterwards, I used TestStand to call my application (VI). The LabVIEW adapters from TestStand were set to Development System by default, and everything works OK!!
Finally, I needed to disable the development system, and set the LabVIEW adapters from TestStand to LabVIEW Run-Time Engine and I notice that the speed of the data exchange between the two COM ports decreased dramatically.
The only difference was the speed...because all the data (changed slowly in this case) arrived correctly on the other COM port too.
The symptom was the same as decreasing the baud rate...but the baud rate and all the other configurations remained the same. The only difference was the change between Develpment System to Run-Time Engine to notice this decreased speed between the exchanged data using VISA Write.
Any solutions for this?
Thanks in advance
Joao
Solved!
Go to Solution.

Joao,
you state that using the LV Developement System as execution platform for your LV code modules result in faster datatransfer between the COM ports than using the LV Run-Time Engine.
So i am pondering: Does this refer to TS at all?
Please check the following:
Run you communication using a sole LV application in LV Developement System. This should be fast. Now build an executable of this application and run that one. Do you see the same behavior?
If there is no difference in a sole LV approach, there have to be some settings in the TS approach making this slow. So please let us know:
Are there different modules involved in that data transfer (which in fact points to the reply Christophe made)?
What about loading/unloading options of the modules?
How big is the hierarchy of the modules, e.g. is it necessary for the RTE to load stuff the Dev Env has already in memory due to loading a lvproj.......?
Could you provide a simple example sequence+modules showing this behavior?
What versions of LV and TS are you using?
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

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

Will hardware drivers work with the run-time engine or only a full version of Labview?

Hello.
I'm trying to get a quatech I/O card to work. The instructions with the drivers we were given state "you must have labview installed before installing these drivers".
A program I wrote on my machine works fine with those drivers and does toggle outputs on the card, but when I build it into an executable on our test unit (doesn't have a full version of Labview, just the Run-Time engine) the card doesn't work.
We installed the run-time engine on the unit, then the drivers.
I guess my question is: Do most drivers work with both the full version of Labview and the run-time engine? Or do I need to somehow 'convert' these drivers to work with the run-time engine?
Th
anks for your help!
Dave Neumann
[email protected]

Dave:
I can't determine which dll is required but if there are more than one that
shipped with the quatech I/O card try to placing one dll at a time in the
same directory as the exe so that you can determine which one is the
required one. If that doesn't do it then it may need more than jsut one of
the dlls so placing all that came with the quatech I/O card s/w driver
package in the same directory as the exe should do the trick.
Best of luck.
-Tom
"Neumannium" wrote in message
news:[email protected]..
> Tom,
>
> Thanks for your reply. One of the problems I'm having is figuring out
> which .dll I would need to include (I'm not a software guy).
>
> Would the .dll your speaking of be different th
an the one which is
> installed with the drivers? I'm looking at a .dll that is installed
> when you install the labview drivers for this card, but the run-time
> engine still doesn't want to get the card to work. (The file installed
> when I install the drivers is called 'daqlv32.dll' and I don't know
> how to find any other .dll's I might need)
>
> Actually, it appears the card 'is' being seen by the run-time engine,
> but I'm getting impulses rather than distinct changes of state.
>
> Anyway, thanks for the help.
>
> Dave Neumann
> [email protected]

Getting LabVIEW load error code 59 using LabVIEW 2010 with a Run Time Engine.

I use a vi compiled with a run time engine to run separate vi’s in my application directory. Once a file association is made with this exe file any Vi in my application directory is available to be loaded as needed. This is a process that has been very successful for me over the years and would prefer to continue using this process. Most of my applications are running in LabVIEW 8.6 and have moved them to 2009. First indications are in 2009 this process is still working. However, I plan to go on to 2010 before upgrading my test stations.
In 2010 I get the error 59: “The source file’s compiled code has been separated, and this version of LabVIEW does not have access to separated compiled code.”
The same dialog box also presents, (Hex 0x626) “Cannot open a VI with separated compiled code in a Run Time Engine that has no access to the VIObjCache.”
What can I do in the build that will get around this error?
Thank you

Thank you for the solution. I am sure this works until the next vi in the vi library gets this option selected.
The bigger issue is I was doing something that National Instruments did not support. When I started in the days of LV 4.0 it was recommended to me that I use this method as virtually all my applications were for in house projects. This is still my preference because it gives the most versatility and allows modifications of single files rather than compiling the entire application.
The final solution I ended up with for those who may be having the same issues. My recommendation for what it is worth, is to compile the application as an executable. This is from what I can tell the only acceptable and supported method. Using this method the problem is solved.
I have accepted this as the solution. I still don't like it. I could list the reasons why but it is a mute point.
Thanks again for taking the time to respond to this issue and offer the solution you found.

Teststand error states that a vi failed to load in the Labview Run-Time Engine

I am getting an error in teststand that states that a vi failed to load in the Labview Run-Time Engine version '14.0.1'
If I look at the software loaded on my system with the NI Measurement and Automation Explorer I have Labview Run Time engines for version 2009, 2010, 2011, 2012, 2013, & 2014 on my system.
How do I get this VI to run on this system when it is called by test Stand?
Thank you

The RTE 14.0 was loaded as part of my deployment and after I ran this I got an update notice for the F1 patch which I also loaded.
I do not have labview loaded on this system, only the run time engines from running my deployment.
When I launch t he teststand sequence, when it calls the labview VI, I get the following error moessage:
Error: Failed to load VI 'C:\builds\RelayVoltageMeaure.vi' in the LabVIEW Run-Time Engine version '14.0.1'. LabVIEW: The VI is not executable. This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it. VI Path: C:\builds\RelayVoltageMeaure.vi[Error Code: -17600, Failed to load a required step's associated module. ]
I have attached the teststand sequence if this helps.
Thanks
Attachments:
QuantumDigitalBd.seq ‏13 KB

NI LabVIEW Run-Time Engine + TCP/IP

Hello, Anybody knows how to activate TCP/IP service on PC with standard NI LabView Run-Time Engine installed. If I trying communicate with server from my PC (LVRTE) its works correctly. However, when I am trying interchange client and server applications it appears with error 1. Probably I need to add some settings to *.ini files on PC with LVRTE? --- Alex

<Alex> wrote:
Client/Server applications are communicate via standard TCP/IP VIs. I have tried to add 3 line as you wrote to server.ini, but it's didn't help
As I indicated, the lines are only applicable to using the VI Server. You had not indicated whether you were using the VI Server or just the TCP/IP VIs. At this point we need a better explanation of what you're doing. Specifically:
What does this: "If I trying communicate with server from my PC (LVRTE) its works correctly." mean? What is the "server"? What's it running? What do you mean by your "PC (LVRTE)"?
What does this: "However, when I am trying interchange client and server applications it appears with error 1" mean? What is the "interchange client" and the "server applications". Reading this implies you have more than one application running on the "server", whatever that is.
Seeing some code wouldn't hurt either.

LabVIEW Run-time Engine 7.1.1 installation failure on Windows 7 SP 1 32-bit

I am attempting an installation of LabVIEW Run-time Engine 7.1.1 on my Windows 7 SP1 32-bit OS computer and the installation hangs. This happens near the beginning. Is there a compatibility issue? The window does not have any error messages. It says: "Updating System, The features you selected are currently being installed." The progress indicator blinks periodically, but does not move forward. Please help. Thanks!

I recently tried to install the LabVIEW 7.0 runtime engine on my Windows 7 (64 bit) machine to try out an old software. Ended up removing it quickly again, since any LabVIEW version I started up after that, including LabVIEW 2013 showed an installation dialog on startup about (updating installation information, please wait!).
Basically there are so many possible problems why it could fail. Apparently the runtime engine installer had played with some other NI component that he had no idea would ever exist when it was created and caused that component to always think it needed to update itself to finalize its installation. In your case it could be anything from a missing Visual C runtime version framework that the installer simply expects to be present but doesn't since Microsoft has in the meantime released about 5 versions of Visual C and doesn't install all runtime versions anymore on newest Windows. Or it could be a conflict with your hyper-duper .Net Framework 4.5.x.y that the installer does not be prepared for. Maybe that or something else was not present on your 64 Bit machine where you could install the runtime engine.
Basically the reasons for the install to fail are legion, and trying to figure it out is always more hassle than moving on and let old software be old software.

NI 5660 Driver DLL Errors when using Teststand 2010 and LabVIEW Run-Time Engine 2010

This problem seems similar to the post "Resource not found error in executable on development machine." but I didn't want to repost under that thread because I only happened upon it by chance and none of my searches brought me there... so I made a more descriptive Subject.
I am working on a system that uses a PXI Chassis with a NI 5600 Downconverter and a NI 5620 high speed digitizer, among other PXI Cards.
I inherited working code written in LabVIEW 2010, running with the LabVIEW Run-Time Engine 2010. The code was using a custom executive and my task was to rewrite the test using TestStand 2010. I reused the majority of the old code. The old code used NI-5660 to control the 5600 and 5620. When I run my sequence using the LV Development System and TestStand, it runs without any issues. When I change the adapter over to LabVIEW Run-Time Engine 2010, all of my NI5660 VIs become broken due to DLL issues. It warns that the nipxi5600u.dll was not initialized correctly. Many of the errors are associated with the NI Tuner and NI Scope. After this LabVIEW will crash randomly, and the seqeunce will not work in TestStand even when back with the LV Development Adapter. The only way to recover after this is to restart the computer - TestStand automatically reverts back to the development system, the VIs are no longer broken and the sequence works again.
I have all of my VIs associated with a project. After reading a little bit about DLLs and TestStand, I found all of the DLLs in the dependencies section of my project and added them to my TestStand workspace. I also used Dependency Walker to track down the problems with the nipxi5600u.dll, the 2 DLL files that it said were not found already existed in the same folder as the original DLL (C:\Windows\System32). I have also performed a Mass Compile to make sure everything was running in LV 2010. If I skip the steps involving the 5660, my entire sequence runs fine.
The previous code was running with the LabVIEW Run-Time Engine without any issues. Is there just a step I am missing? Has anyone seen anything like this before? I can send screenshots of errors to provide more detail if necessary.

I have tried some more things and still can't get it to work. I have added the VIs mentioned in the Notes On Creating Modulation Executables KB both to the TestStand workspace and the LabVIEW project holding all of my VIs. This did not change the results.
When I try to run my sequence, The first error I get is shown in Error 1445.bmp. This happens when I try to use the NI 5660 initialize.vi. If I click ignore, the next error I see is shown in Error -20551.bmp. When I try to open the VI to look at it, I get the 2 DLL errors shown in Error loading nipxi5600u.bmp and Error loading nidaq32.bmp. When I close TestStand, I get the error LabVIEW Fatal Error.bmp.
Attachments:
Error1445.JPG ‏164 KB
Error -20551.JPG ‏174 KB
Error loading nipxi5600u.JPG ‏9 KB

Install labview 6.1 (or compatible) run-time engine with labview 2011

I have installed a trial period version of Labveiw 2011 in order to check for possible upgrade issues I may have if I decide to upgrade from labveiw 6.1. Well, needless to say there have been alot. That is as expected since I have not updated labview in many years. I am still not under any pressure to update; however, I would like to in order to get support and make sure I do not have any compatibility issues with new equipment purchases. I have been able to resolve most of my compatibility issues with simple code fixes and such. However, twice now I have run into an error when launching labview executeables compiled by two different equipment manufacturers. The equipment I am using is not even old...maybe a year or so. When I launch the labview executables to control this equipment on a PC that has the trial period labview 2011 installed, I get an error message stating something like " This requires a Labview 6.1 (or compatible) run time engine." I have tried to download and install the 6.1 labivew engine but I can't install this engine on a PC which has labview 2011 installed. Can someone explain how I am to run these executables under labview 2011. I can't imagine these executables were developed using 6.1 since this equipment is not even a year old now.
Solved!
Go to Solution.

Im not for sure I am on the same page with you here. Im not trying to develop any code myself. I have some labview executables that came with hardware we purchased in order to control it. We used to have labview 6.1 installed; so everything was working ok. But now that I have installed 2011, I get an error message when trying to run these executables. The error message states that this executable requires a labview 6.1 or compatible run-time engine. I have seen this error on both XP and Windows 7 machines. I did not develop the executable, it was developed by the hardware manufacturer. But since this hardware is only about 1 year old, I an assuming they used a newer version of Labview to develop this code. Certianly newer than 6.1.
So I guess my question is..is there a way for me to get this executable to work on a PC that has labview 2011 installed. I have tried to install a labview 6.1 run time engine but it will not install. Any other options?

Building an Application in Windows to be used in Linux (with the Run-Time Engine)

Hi All,
I have an LabVIEW project I have developed in a Windows environment. I can create an Application (.exe) using the Build Specification -> Application Builder which works fine on the development platform.
I now want to distribute the application to a Linux Environment. The OS is openSUSE v10.3 (with GNOME). I have downloaded the two rpm files needed for the run-time engine and installed them, as per here:http://digital.ni.com/softlib.nsf/websearch/97E14BA3E0C14A89862572C300567733?opendocument&node=13207...
Now, the question is; how do I create an Application in Windows which can be used on the Linux Box? According to the Application Builder instructions, it's simply a case of removing the .exe extension in the Target File Name options, however, this gives an error "Invalid Extension."
If I do create an exe and manually remove the extention is doesn't work on the Linux enviroment (typing ./application).
Has anyone had experiance of this?
Many Thanks for Any Help,
Oliver
Windows XP SP 2
Labview 8.2.1
openSUSE v10.3 (with GNOME)
LabVIEW Run-time Engine Version 8.2.1 for Linux

The cross-platform nature of LabVIEW refers more to the code than to the executable.
LV (given the appropriate development version) can compile the same source code into a Windows (using LV for Windows), Linux (using LV for Linux) or Mac (using LV for Mac) program.
This means you will still have three versions of your program, one for each platform.
If you want to distribute VIs (without block diagrams), you will also need different versions of these as without the block diagram, they cannot be re-compiled for a new platform.
Shane.
Say hello to my little friend.
RFC 2323 FHE-Compliant

LabVIEW 2009 SP1 Run-Time Engine (Minimum) (32-bit) for Windows - Supported Features

Hi,
Can some one please point out what features are supported by the LV RTE (Minimum ) [LabVIEW 2009 SP1 Run-Time Engine (Minimum) (32-bit) for Windows]
1) Is there a limit on the size of the exe which can be run on it?
2) Will this support additional modules like DAQ etc.,? Or do we have to chose the regular installer ( 170 Mb ) for that purpose?
3) If a list of what it does or does not support is available, it would be extremely helpful.
Thanks In advance.
Regards,
Vijay

Anand,
I did go through both the links that you had sent earlier before posting on the forum. For eaxample refer the following link where it says,
http://joule.ni.com/nidu/cds/view/p/lang/en/id/1599
It does not contain the full run-time engine, but will allow some executables to run.
1) What do they mean by 'some' executables. Is there a list of yay's and no's available?
2) Can someone from NI reply to this and shed more knowledge?
Regards,
Vijay

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

Installshi​eld Merge Module Rather Than Run-Time Engine

Similar Messages

Maybe you are looking for

Installshield Merge Module Rather Than Run-Time Engine