Labview 8 Application Builder and VISA Runtime Engine

Hi,
I am using Labview 8 Application Builder and everything is working fine except for 1 small thing. My program makes use of some of the VISA functions and when I build the application I'm having to include the VISA Runtime Engine Installer as a separate item on the CD to make the .exe file work.
What I would ideally like is for people who want to use the application to run the installer and that all necessary components (including the VISA Runtime Engine) are also installed in the one installation. At the moment they're having to do 2 installations and I would like to streamline this.
Is this possible?
Ken

Hi,
  this How-To explains about making those selections and including the different drivers :
http://zone.ni.com/reference/en-XX/help/371361A-01/lvhowto/add_installers_to_build/
and this tutorial covers the screenshots a little more step by step.
http://zone.ni.com/devzone/conceptd.nsf/webmain/5ADBC06AC32E508A8625706E0062EBD1
Hope that helps
Sacha Emery
National Instruments (UK)
// it takes almost no time to rate an answer

Similar Messages

  • Can visa runtime engine be included in application build?

    I just installed my program on a new machine and it wouldn't work. Turned
    out I needed to also install the visa runtime engine. Is there any way to
    automatically include that in the application build?

    I've seen that you can tick of under the "additional installers" that Visa runtime is included, however, this will look for the installer files on the CD's. Is there a way to update this ? (I have 4.0 on the disc, and would like to included 4.2 in my build for installation/deployment.
    The file I download from NI is a .exe, but the linking to the build configurator is some strange windows code (see attached screenshot)
    /Brian
    Attachments:
    screenshot 13-08-2007 17.57.JPG ‏95 KB

  • Application Builder and Corrupt VIs

    Howdy All,
    I'm developing a Medium-sized application in LabVIEW 7.0 used for instrument control. This application has grown over-time, and currently contains approximately 400 VIs. The basic structure of hte appliation is one main VI that has an instrument status display on the bottom, and a sub-panel on the top, into which all dialogs are loaded for user interaction. Each major task has it's own VI that is loaded into the subpanel as appropriate.
    I've read a few stories on the developer exchange about VIs becoming corrupt. I thought these were freak occurences, because by and large, it appears that LabVIEW is fairly stable. However last week I had a VERY scary experience.
    I was demonstrating to a collegue the properties of an XY graph control. We changed the colour of one of the plots, then hit cancel. LabVIEW complained of an internal error involving undo.cpp and proceeded to crash. I figured the crash was caused by some strange sequence of events, didn't think much of it, and reloaded my application. After making some changes, I went to the Application Builder to build the application. However the application Builder was complaining about a "missing board" in the DEFAULT build file. I knew immediately that something was VERY wrong. (When I say default build script, I'm referring the default script that is loaded when you press the "Build application or shared library..." button in the tools menu).
    (As a side note, does anyone know why the LabVIEW application builder gives such terrible error messages? I always get that "missing board" error when either: one of my support files cannot be found, or one of my dynamic VIs is not executable. Since the error doesn't pinpoint a file, I neeed to go through the files one by one - which is a pain because I have a lot. Another question, why does the application builder ALWAYs ask if you want to save changes to build script, even if you haven't made any changes?)
    After loading my build script for the application (which I've used HUNDREDS of times), I got the "missing board" error. I didn't think there was a problem with any of my paths or VIs, but I went throgh each included support file and dynamic VI in the build script to make sure it was there. Though there seemed to be no problems with any of the files, LabVIEW continued to complain.
    I figured the problem was specific to the computer I was working on, so I copied the source to another development machine to complete the build. I was VERY scared to find that I got the SAME error on the DEFAULT build script! Also, my actual build script refused to load properly.
    This was late at the end of a long day, so I decided to turn of my machines and go home. The next morning, everything worked fine - I was able to build the application, and I haven't had a problem since. (Maybe it was a bad dream, but I have clumps of hair on my desk from the night before...)
    I found this experience to be UTTERLY TERRIFYING. Once I had to revert to an archived copy of one of my main VIs, because the current version refused to open, claiming it was corrupt. Since I don't know what's going on behind the scenes in LabVIEW, I'm afraid that tiny internal LabVIEW errors might be adding up. I back-up the source very regularily, since it is such a large project, however I have *real* way of inspecting the integrity of the source.
    Does anyone know (A) why this might have happened - especially when the problem reproduced itself on multiple machines (B) has anyone had similar experience with internal LabVIEW errors or corrupt source (C) what sort of internal errors might be piling up that might cause a VI to claim it is "corrupt".
    All input is appreciated.
    WG

    Hi Robert,
    For the undo.cpp error, I got a couple different line numbers but didn't write them down. If I get them again, I'll be sure to get the specifics for you.
    As for the "missing board", I also got that description a little wrong - the error I'm talking about is:
    "Error 7 occured at Inovke Node in Dist read linkages.vi->Dist Cmp Settings to Disk Hier.vi->Build Application.vi
    Possible reason(s):
    LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for hte operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Unix.
    NI-488: Non-existent board."
    As you can see, I meant "non-existent board". This error is very easy to reproduce - m
    ake a build script and include some extra files. Save and close the build script. Move or rename some of the extra files included in the build. Reload the script. You should get that not very helpful error.
    Now that I think about it though, maybe that NI-488 error refers to GPIB control, which I think I have installed, but don't have a GPIB card installed... hmmm... no reason that error should be popping up *there* though...
    I could have *sworn* I would also get that error when one of the dynamic VIs in the build is not executable, but I can't seem to reproduce that right now.
    Tying back to the original thread - what makes a VI corrupt? I imagine if you cracked the binary file open yourself and messed around with some bits you would probably make the VI corrupt, but I'm assuming that editing a VI normally (ie through LabVIEW) should NOT cause the VIs to become corrupted. Any information on VIs becoming corrupt? Is it somehow related to the undo.cpp errors?(when trying t
    o undo some last change that wasn't recorded properly, the VI is modified improperly - after you save and close, it won't reopen?)
    Victrick

  • NI VISA Runtime engine

    When "Building" a LabVIEW program containing NI-VISA sub VI's (e.g. to communicate with USB), I have had problems getting the "Built code" to find my NI VISA devices, even though the NI VISA USB  Drivers are correctly installed on the "target machine".
    (The "built" code WILL run if the target machine has a LabVIEW installation on it, including NI VISA)
    So - will the NI VISA runtime engine be automatically included in the "Build" (Because of the NI VISA sub VI's), or do I have to specify this myself - And how?
    Thanks. Peter.
    Solved!
    Go to Solution.

    You specify installing the NI VISA Runtime Engine when you build and installer for your built executable. Look on the Additional Installers tab of the Installer Properties Dialog Box.  The NI VISA Runtime Engine should be selected automatically but if it's not you can uncheck the Automatically select recomended installers checkbox and select any other installers you want to include in your install.
    If you're not using an installer then no runtime engines are installed and you'll have to do that manually on each machine you copy the executable to.
    This all assumes LabVIEW 2013.  The selection process is slightly different in earlier versions but all the options are still available.
    Kelly Bersch
    Certified LabVIEW Developer
    Kudos are always welcome

  • Is LabVIEW application builder needed for TS deployment?

    Does the LabVIEW application builder need to be installed for TS deployment of a project containing LabVIEW VI's?

    LabVIEW Application Builder is only necessary if you are deploying LabVIEW files, even then you can use the flag "Include without Processing Item or Dependencies" in all your LabVIEW files to create an image and optionally an installer without requiring LabVIEW (or app builder) at all; however, using this flag is not recommended becuase if you use it you would have to include all the files and their dependencies in your deployment manually (either by including the root directory of your test system or by adding all the files to your workspace) and you would have to make sure that they are not broken and can be called from the run-time engines you are including in your installer. 

  • Application Builder and Demostration App 4600

    Besides poking around in the f4600.sql file for pages 1-30'ish AND looking at some of the source code provided at the bottom of each page, is there any better way to (using the Application Builder) to learn how these demonstrations were developed? I'd actually prefer to open in the Application builder and see the properties along with the SQL and PL/SQL.

    tx100118 wrote:
    Besides poking around in the f4600.sql file for pages 1-30'ish AND looking at some of the source code provided at the bottom of each page, is there any better way to (using the Application Builder) to learn how these demonstrations were developed? I'd actually prefer to open in the Application builder and see the properties along with the SQL and PL/SQL.Just import the <tt>f4600.sql</tt> file and install the app in your workspace. It won't run because it's missing the supporting db objects (obviously installed from elsewhere during the APEX install process), but you can explore how it is constructed.

  • LabVIEW application builder - Deep start menus

    Hi, is it possible using the labVIEW application builder to create start
    menu program groups that are more than one level deep, i.e.
    Start\Programs\My App\Tools

    Just for you to compare I have attached some screenshots of my setup. Maybe you find a difference.
    Attachments:
    App_Builder_Setup.gif ‏152 KB
    App_Builder_Menu_example.gif ‏83 KB

  • Several question s about runtime Engine, application builder and labview player

    I am a little confused by all the options to distribute a program.
    Please help bij answering (one of) the following questions:
    1. Does an application built with the application builder always need the LV runtime engine? The LV runtime engine is 33 Mb to download!
    2. Is there anyway to make a 'normal' executable that runs on a windows machine, without any supporting installed software?
    3. What is the advantage of the labview player above the runtime Engine?
    All questions refer to the latest software versions of NI software
    Thanks in advance,
    Regards,
    Ferry

    ferry1979 wrote:
    1. Does an application built with the application builder always need the LV runtime engine? The LV runtime engine is 33 Mb to download!
    Yes, the runtime engine contains all the stuff that is common to all LabVIEW applications. This is not any different than e.g. the Visual basic runtime (VBrun...) or dforrt.dll for Fortran.
    If you built the application, you can strip it a little bit by including the runtime with the installer and leaving out unneeded modules (see image from the 7.1 builder).
    The advantage of a seperate runtime engine is that applications are very small. The runtime needs to be installed only once. On any broadband connection, 33MB is peanuts. I distribute everything without runtine, but tell people to download and install the runtime directly from NI.
    (In LabVIEW 4, no runtime was needed, with the disadvantage that even the simplest program was multiple megabytes. Not an efficient solution).
    (Maybe in a few years LabVIEW will be so prevalent that the LabVIEW runtime will be part of a standard OS install ;
    2. Is there anyway to make a 'normal' executable that runs on a windows machine, without any supporting installed software?
    No. See above.
    3. What is the advantage of the labview player above the runtime Engine?
    The two are quite different. The labview player is more a simple educational tool, because it lets users inspect the diagram. It is not designed for any serious application deployment.
    Message Edited by altenbach on 08-21-2005 10:05 AM
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    runtime.png ‏24 KB

  • Application builder and dynamic class VIs name collision

    I'm, using LabView 8.6 and I'm trying to make executable file. 
    The application builder returns warning:  
    "LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts."
    ...and no executable is created.
    I'm pretty sure the warning comes from the fact that I use dynamic class member VIs, that are by definition have to have same names in both parent and children.    
    The following link (http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/caveats_apps_dlls/) says " If you don't rename the files, Application Builder moves the files to different folders for you to avoid a filename collision.", but no folders are created.
    Any help here? 

    Hi,
    If you have a parent class and one or more child classes, during the build LV will create a folder for each class with a conflicting VI.  The offending VIs will be dumped in their respective folders, resolving the conflict.  For what it's worth, I've used dynamic dispatch VIs several times in executables in LV 8.6 without seeing the issue you're reporting.
    My only advice would be to:
    1) make sure that you haven't somehow put two VIs of the same name in the same class (not even sure that's possible).
    2) make sure you aren't renaming a VI during the build and creating a conflict
    JasonP - CLD

  • Problems with Application Builder and NI-DAQmx drivers in Labview 8.2 Professional

    Hello everyone,
    I am trying to use the application builder to create an executable so that someone without labview is capable of a remote panel connection to connect to our test laboratory.  our test laboratory uses the USB Compact DAQ  9172.  I did find some other forums that ran into a similar problem where a computer that didnt have labview installed on it looked for a particular driver (nilvaiu.dll).  The common solution appeared to be when building the installer, include the current NI-DAQmx (8.3 in our case) option and then the clients worked fine.   My question is when i use the application builder to create an installation file for this application, i get a prompt to:
    Locate the "National Instruments Device Drivers - February 2006 Disk 1" distribution. LabVIEW needs to copy a component installed or updated by the distribution to continue building the installer.
    What is confusing is that the installation cd's in our laboratory are from August 2006 (501165N-03).  It didnt make sense to me that i would need to downgrade the drivers from a few months ago, but i've been wrong before.  We just upgraded from the full development to the professional version about 2 weeks ago to utilize the application builder function.  Has anyone else ran into this problem and could this be a limitation because we purchased the software with the academic discount?
    thanks in advance
    Chris

    Chris,
    My "fix" is brute force.  Backup everything.  Removing all the NI software takes a while.  Be sure to remove leftover directories and files. 
    Altering the windows registry takes seconds and is not hard if you know what you are looking for.  I've attached a screen shot with the NI entry selected.  This is what I  deleted on by machine.  The thing to remember is that the registry controls all the software on your pc.  Delete/alter the wrong entry and you have problems.  Worst case scenario is that you could end up formating the hard drive and starting over from scratch.  I'm not trying to scare you, but I want to make sure you understand the potential for harm. 
    One thing you might try first.  NI-DAQmx 8.5 is now available for download from NI.  You might try unloading 8.3 and installing 8.5. 
    Attachments:
    regedit pic.JPG ‏102 KB

  • Installer build wants wrong runtime engine

    LabVIEW 8.6
    Windows XP Pro
    When I build the installer for my application, it wants me to have available the install disk from November 2007.
    Expanding the list for that disk, I find that it wants the runtime engine for version 7.1.1.
    If I remove NI-DMM 2.9 from the 'National Instruments Installers to Include' list in the Installer Properties, the error goes away.  The description for that installer indicates it comes from the August 2008 device drivers disk.
    At one time I had other versions of LV on the computer.  I have removed all other versions, including the directories in c:\Program Files.
    My application uses the DMM device driver, so I assume that I need to check the box for the additional installer.  I've looked for more documentation on when and why I should select different items in the list, but couldn't find anything useful.  Would it be possible for the installer to automatically select those items required and perhaps let me direct it otherwise by choosing fewer or more items?
    Bottom line, do I need to select the DMM driver to ensure that my application will run on a computer that doesn't have LV installed?
     - les

    Hello all,
    I couldn't really understand what was doing on in the above questions and answers but from the forum topic I believe I am in right place. I have an issue similar to those desscribed above. I have LabView 8.6.0 installed on my computer but when I run LabView it starts asking for 'NI LabView Runtime 7.1.1'. I tried feeding in the labview 8.6.0 but it doesn't accept it and keeps asking for 7.1.1.
    The program used to run fine couple of months back and I then didn't use it for a while and I had other prgrams installed durig this time. And when this month I tried to use LabView it started giving me this trouble. I don't know what went wrong. I installed some ftdi chip drivers also. So, I am thinking if that kind of messed things up.
    Also, I have this windows installer message come up sometimes which is not when I open LabView but some other programs. I don't know if this windows installer has to do anything with it.
    Whatever the case it is could someone please help me figure out how I can get the right runtime work for my LabView 8.6 and if also possible how i can get rid of this windows installer message. I don't remember the error code right now because it comes up randomly. Next time I see it I am going to save that number. But in the meantime if anyone can help me with LabView 8.6. runtime engine problem.
    Thanks,
    Lovepreet

  • Using the LabView application builder

    Hi.. I'm trying to build an application from my labview project and I want it to run it in a computer with no Labview installed. When I'm trying to run this Error shows up: Unable to locate the Labview Run-time engine. Is It possible to run my application in this computer? or definetily I have to install Labview on it in order to run it.
    Thank you

    You need to install the LV runtime engine corresponding to the LV version of the development environment.
    This can be easily accomplished by creating an installer for the executable. Also an option in the project build menu.
    Otherwise search the Ni website and download it.
    Regards,
    André
    Regards,
    André
    Using whatever version of LV the customer requires. (LV5.1-LV2012) (www.carya.nl)

  • Application builder and CWGraph3D

    Hello all,
    I am trying to build a self-executable 3D plotter for a fellow worker using the CWgraph3d. When I go to build the application with application builder I have no issues. When I install the application of the host computer and try to change the 3D plot properties, I am not given the options as when I ran the program inside of LV....Any ideas on what I am doing wrong?
    Thanks,
    Jay Poret
    AOT, Inc.
    [email protected]

    Travis,
    I am still a little confused....All I am trying to do is to make a self-executable 3D plotter that allows me to change things like the scale, titles, etc. I did find a way to use property nodes to bypass this but I am still interested in why the example didn't work. Here are the steps I followed:
    In application builder
    1) insert the cw3Dgraph.ocx as a source file
    2) Use the advanced tab and have the program insert the file in the c:\windows\ssystem32 folder (I confirmed the installer did this)
    Outside application builder
    3) I registered the .ocx file externally using start>>run>>reg32 c:\windows\system32\cw3dgraph.ocx (when hitting enter the system confirmed that the .ocx file was registered on the computer).
    Run executable....I could make 3D graphs, rotate the plot but I could not change the x,y,z scales or anything like that.
    Am I missing something here?
    Thanks for your help.....
    Radman
    Travs H. wrote:
    Hi Radman!
    Maybe Robert will have more to add, but I'll throw in my 2 cents worth :-)
    When creating an executable/installer, setting Top-level VIs is what designates what VIs actually open and run when you double-click your exe file. By adding both the DS 3D Graph Reader & Writer as Top-Level VIs, you are indicating that when running the executable you want both of those VIs to automatically open and run.
    Now about your concern for the batch file. This document was originally created before the release of Windows XP. With that being said the following:
    "Then, set the Installation Destination to be Windows System Directory. This will put the ocx into the System32 directory on NT, ME, and 2000, and the System directory on 9x."
    should read:
    "Then, set the Installation Destination to be Windows System Directory. This will put the ocx into the System32 directory on XP, NT, ME, and 2000, and the System directory on 9x."
    Also, if you need to have the ocx file in different directories depending on the operating system (XP or 2000), you will just need to make two versions of the exe. A WinXP version and a Win2000 version.
    Hope this helps!
    Travis H.
    National Instruments

  • Application builder and Installation

    Elijah Kerry did a real nice power point presentation on Application Builder ( Risk Associated w Source Distribution)  back in 2012.  I can't remeber what forum/group, etc I found it under.  Does anyone know if there is a similar presentation for creating an Installer??
    ie:
    How do I make sure I get all the files needed to port my code to a target machine?
    Do I need to create the exe file 1st??  or does Installer do that for me??  What about MAX??  What about DAQ??  etc, etc.???
    Thanks.

    Jeff·Þ·Bohrer wrote:
    Yes.  Tasks Scales and chanels need to be defined somewhere.  That *.xml file with a *.lvproj extension is a nice convinient place that DAQmx will look for.
    Excuse my ignorance on the subject because I've never used it.  But is this useful for deploying DAQmx scales/Channels/Aliases?  When I build an EXE and then an installer is the DAQmx scales and channels information inside the .lvproj imported?  Or is this just useful for development?
    EDIT:  It looks like it only has scales/tasks/channels not aliases.  So never mind.
    Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
    If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

  • LabVIEW Application Builder Crash : ntdll.dll faulting module

    Hello guys,
    I'm currently experiencing problems while building my project (LV2012 (32 bits) , Windows 7). At the very end of application build, LabVIEW crashes with no explanation (Screenshot in french, sorry)
    Windows error logging follows :
    Event 1000 Application Error
    Faulting application name LabVIEW.exe, version : 12.0.0.4024, time stamp : 0x4fea600e
    Faulting module name : ntdll.dll, version : 6.1.7601.17725, time stamp : 0x4ec49b8f
    Exception code : 0xc0000374
    Fault offset : 0x000ce6c3
    Faulting process id : 0x16fc
    Faulting application start time : 0x01cda5350f41f87c
    Faulting application path : C:\Program Files (x86)\National Instruments\LabVIEW 2012\LabVIEW.exe
    Faulting module path: C:\Windows\SysWOW64\ntdll.dll
    Report Id : 8e5b1344-1128-11e2-97d8-c0f8dae81bad
    I had the same problem on LabVIEW 2011. I tried to build my application with another computer (also LV2012 32 bits and Windows 7 64 bits) and I do not have any error.
    What is wrong with my computer?
    For french people, topic in french
    Thank you for your help,
    Regards,
    Quentin
    Solved!
    Go to Solution.

    Solution found :
    -Uninstall all NI products
    -Clear registry keys related to LabVIEW
    -Delete National Instruments directory into Application Data
    -Reinstall LabVIEW

Maybe you are looking for