LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I would like to include arguments for any/all shortcuts from the installer. Currently you can build a labview installer to put shortcuts on desktop and to the "Program Files" menu. But there is no option to include arguments. See attached image of how it would look in labview.




This would allow for the installer application to include file path arguments into any executable. Example: You want to include a tftp server application for the installer and embed the tftp path in the shortcut.


It could also be usefull to run the same labview app with many startup arguments. Like if you have a debug mode and normal mode. If you want to include both options on the desktop you could use a -debug as the argument. And include it in the shortcut from the installer. Both shortcuts would point to <application> but one would also say "<application> -debug"





Although new folders can be created in the application and installer build specifications, they are not created unless a file is put there. An empty folder is desireable for data output. It would be better for it to be created before running the application so that security access rights can be set by the person doing the installation if administration priveleges would otherwise be needed to create new files there. It leaves quite a bad impression on those who waste time finding out by trial and error that the folders defined in the build specifications are not created. The forum also documents complex schemes to work around this limitation by people who surely would rather have been doing something productive instead.

If you are going to call it a developer suite, put the developer tools in it. The following toolkits need to be added:

Of course this will increase the cost of the developer suite. I find it easier to convince my boss to approve a cost increase versus purchasing a new toolkit.

With LV comes a decent icon editor. It's the one that starts when you look at Build Application settings -> Icon -> Icon editor.

This seems to be the only way to start this program, there's no entry for it in the Programs Menu.

So what i've done is to create a shortcut to iconedit.exe and add it to my Programs Menu, and i feel this should be part of any and all LV installations!


So: Add an icon to Lv's Icon Editor as part of the installation.



I suggest that NI clearly mark those functions in IMAQ that require a run-time license.  Perhaps color their icons pink or some noticeable color.  There is a lot of misinformation in NI technical support regarding this issue.  I wasted a lot of time developing an IMAQ program and found out later that it required a run-time license that my client did not want to buy.  So, I had to rework the code to eliminate those functions that require a run-time license.


admin note: Invalid link has been removed.


All the other Build Specification has already this function available. Why not the Installer and the ZIP File.



Installer needs option to conditionally install files.
In some installs, like a new install, the installer should install a file but that same file should not be overwriten on an update. For example, a database file that is updated by the user will be overwriten by the installer.
The options required are:

  • Install file if not present.
  • Install file or not install if file is modified. 

InstallShield should be consulted for the various options required.

It is nice if one can select which driver to download, specifying the version.


Currently it is only "Device Driver" item in the web-based installer. By using this option, user must download very huge driver ~10GB.


LabVIEW 2016 Platform (web-based installer).png


It is very helpful if one can select only necessary drivers like the UI of RT software installation which allows users to choose version such as NI-XNET 16.0, 16.1, or 17.0

Whenever I install a new version of LabVIEW, I have to wade through the LabVIEW options to change all of the UI settings to what I like. To make the upgrade process easier, I would like to see a dialog that:


  • appears on the first launch of the new LabVIEW version
  • can be easily skipped by users who would rather configure things manually
  • allows users to choose common settings (aimed at users without another version of LabVIEW on the machine)


  • provides a user friendly way to import settings from an older LabVIEW version (aimed at users who are upgrading LabVIEW)


This would make the process of upgrading much easier, especially for users who have very particular preferences. Some options that could be addressed in the wizard are:


  • control style (icon or not)
  • visible palletes
  • showing text for VIs on pallete
  • broken wire Xs
  • etc...


Provide an option to display a QR (2-D) code in the product activation dialog.  The QR code should contain a web address that would return the activation codes for all selected products.  For those of us stuck out in a lab or factory with only our smart phones this would provide a slick, foolproof way to enter all of the data needed.  It would save us from either making a round trip back to civilization (with a pad full of info) or getting carpal-tunnel trying to type all that stuff in on a little soft keyboard (multiple times for multiple activations = hand cramp).  We would still have to type the resulting activation codes into the LabVIEW activation screen but that's a lot easier than all the rest.


Idea details:

1) Provide a http link as a QR code 


2) Have the target web page auto-generate the activation codes and display them (preferably in a mobile browser friendly format)

3) As an alternative, let the user upload a picture with the QR code to the NI activation web site for the same result (works for anyone with a camera not just smartphone users -- this would also let you show off IMAQ.)

4) Profit


(And, once you have the QR-code generation code available, add a VI for it to LabVIEW -- see



This is not directly related to LabVIEW but I haven't found any other thread which seems like a better fit. I'm posting it on the Idea Exchange since this is the best place for other customers to potentially agree with me.


NI drivers/software are quite often large, and above 1 GB is not uncommon and sometimes above 3 GB. Having everything in a single file is in my opinion a good thing because I don't have to look for multiple driver parts and download packages, but the file size must be matched by the download speed. Waiting three-four hours or more to download a single driver is not a fun thing to do and quite often you need more than one driver.


Sometimes the speed is okay, but as a general rule I would say it's slow. I'm located in Sweden and of course this issue is dependent on a lot of links between where I am located and the server where NI host the files.

But, download speeds of 200-300 KByte/s from NI are not uncommon but I can run speedtests on for example and get download speeds at 50Mbps using American servers.


I don't know how NI host the files, if it's internal servers or something else but it would be nice if NI looked into the possibility of somehow making this faster.


Currently if you commit to installing the full NI Developer's suite and something goes wrong with the installation you can forget about using the Windows Restore feature because the installation process creates a new Restore point about every 1-3 minutes.  That is unnecessary and problematic for a number of very obvious reasons.


Untitled picture2.png

Consider expanding programmatic modification of the Build Process.  There is already an Idea here to allow the Pre-Build Action to set the Version Specification before the Build Process (it happens during the Build process, after the before-the-change Version Specification has been cached and used in the Build).  However, other Specifications in the Build Spec would be very useful to be able to specify in a (true) Pre-Build Action.

  • Target Filename (low priority)
  • Destination Directory (I like to put Builds in Public Documents, but the Public Document folder can "move", though LabVIEW's Get System Directory can find it, so I could "pre-build" a path specific to the given PC)
  • Build Specification Description (allows the user to include version-specific or Build-Time text)
  • Version Information (in addition to Version Number, before being used, the other Fields might be useful).

I've noticed references on the Web to automated Builds, and know there are Build VIs that will do a Build.  I also know there are a set of "barely-documented" APIs that some have used for this purpose, but I don't know (other than the Set Version Specification, which doesn't work as I expected in a Pre-Build Action) of others.  I don't especially want to poke around inside the Project's XML file -- can we consider adding some other "Pre-Build" Set functions?  Could (for example) some of these "Build Properties" be set with a Property Node?  Maybe this functionality is already there and I've not found it ...


Bob Schor

Does this idea need any more explanation? If someone swipes the box out of a mail slot at work and installs it at home, that becomes the "at home" installation. 


I realize Ideas with pictures do better, so here's a Golden Retriever puppy...



Message Edited by Broken Arrow on 06-11-2010 07:40 AM

If I'm the first to post this Idea then I'll be shocked.

The Idea is simple. We all love programming in LabVIEW, and I'm sure that we've all at one time or another had a colleague, friend or family member ask if we know how to do something on the PC. The immediate thought is I don't know where to get the software to do that, but I could write a simple LabVIEW app  in a few hours that does the job.

E.G hunt through someone's PC and move all of the jpg files over a certain size to a specific location so they can easily find their holiday snaps.


You can't create this simple function for them, because if you do, and build an exe, they still need the Runtime engine.


Surely for REALLY simple stuff (File IO, basic comms stuff in the Base LabVIEW edition ...) - not DAQ or anything like that it is possible to create an EXE that INCLUDES the runtime components that it needs and is stand alone.


This would open up LabVIEW for the use of making quick gadget like apps for the office as well as test and measurement.


I can't se how this could be a bad thing.

Currently, the version of the packed project library (PPL, extension .lvlibp) is defined by the build script which creates the lvlibp.

It would be nice to have an option there to "hook" the version of the lvlibp to the version of the lvlib, which is used for the PPL.


Build Settings Version.PNG


The advantage is to match the developement version of the lvlib to the deployed version, the PPL.

Currently I use LabView through a Windows VirtualBox on a Linux Mint machine. I was told by a customer support employee that I should bring this idea to this forum. I chose this method because of the limited support for Linux even with the supported distro discs. I encourage NI to expand their Linux-compatible software to have the full capabilities that the Windows and Mac versions do for the distros that are currently out, and to expand the number of distros supported. Linux Mint is one of the most widely used flavors, and yet there is no support from NI.

This is in addition to New LabVIEW Installation Retains Options


During LabVIEW installation if it detects a previous version of LabVIEW has been installed it should present the user with the option (or have a flag when running the installation to allow this to be done silently) to import all VIs which are not installed by default that are present in the following folders:

  • vi.lib (VI Package Manager installs packages to this location by default)
  • instr.lib
  • user.lib

Upon importing the VIs to the new LabVIEW installation it should also mass compile them to the new LabVIEW version so the user is not faced with having to save loads of VI dependencies each time the user opens a VI which uses them.


This would make the getting started with the new version of LabVIEW a lot more seamless when just upgrading from a previous version.

Activating an NI Software licence on a computer without internet access works fine but take too long and is user mistake prone because we need to type long strings of characters.


Now we have to :

 - go on PC/tablet/smartphone that has internet access

 - go to,

 - select the product type,


 - select the product version (be carefull to select the version we installed, not the version we recieved*),

 - type the serial number,

 - type the computer ID,

 - then we obtain the activation code that we have to type on the computer.


Bold steps are human-error prone.


If you've done that once from a smartphone, you know how painfull and error prone this process is.

This process should be shorter and much less error prone, something like :

 - the PC without internet show a QR-code that contains product type, version needed and computer ID,

 - launch the "NI Soft Activation" app on your smartphone

 - scan the QR-code

 - type the activation code given by the app onto the computer.


Only one human-error prone step in that process.




* : when you purchase a runtime licence from NI you automatically recieve a serial number that can activate the most recent version of the product, but you can use it to activate older versions of the product as well. Say youwant to activate Vision Development Module RTE 2010 but you recieved a serial number valid for up to version 2012, when you go to the you have to be carefull to select the correct product version (2010 in this case), one more possible human mistake.

The Vision Utilities are currently installed with either the Vision Acquisition Software, Vision Development Module, or NI-IMAQ.  Since NI-IMAQ is a free download that anyone can install and deploy without any additional licensing it makes sense to include it in the LabVIEW installer.


The Vision Utilities provide superior image management , are owned by NI-Vision (meaning they are actively developed), and best of all are free.  Including the Vision Utilities in the LabVIEW installation will expand their exposure and use.  Below you'll see the first three results returned when one seraches for IMAQ on and sorts by examples.  In addition to the examples shown below you can find a list of all the VIs currently included for free in NI-IMAQ here.


Region of Interest Spotlighting With IMAQ Functions                

Spotlight front panel.png 


Semitransparent IMAQ Overlay

Front Panel.png


IMAQ Skew Image