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: 

Do you have an idea for LabVIEW NXG?

Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

Unbelievably NI has introduced a bug into LV 2016 whereas the "Open/Create/Replace File" function does not display the input prompt to the user.  In fact no File I/O functions will display the inputed prompt.  Worse yet there are no prompts for finding or opening files within LabView itself.  Try opening a vi, there is no prompt whatsoever.  In previous versions of LabView there is a prompt telling the user what to do.  e.g. "Select File to Open"


This is very bothersome when you open a vi that cannot find a called vi.  Prior to 2016 there would be a prompt telling the user what vi it is looking for.  Now you are left to guess what vi Labview cannot find.


This is a huge problem for me as I prompt the user to find files and folders in a  great deal of my code.  If I were to upgrade to 2016 I would have to go through 100's of vi's and add dialogs telling the user what to do prior to calling any File I/O functions.


The most disturbing aspect of this issue is that NI did not fix this bug prior to releasing 2017.  It is beyond me how this bug could have made it to another version.  This bug alone requires a fix and an upgrade for both 2016 and 2017 immediately.

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


If we got an option to auto upgrade all the deployed executables in the network. In case of new version is getting released. Like the update features avaliable in all mobile applications.


This will be very useful in case same application is being deployed in many places and needs to get upgraded after the new release.




Would it be great to have free labview license that would allow to read VIs and save them to the previous version you have?

Immediate upgrade to new version does not happen in my case. I can not justify it for my boss, it adds a lot of work to upgrade all customers to new version, I hate idea of supporting multiple versions of code.

The main reason I need later version(s) is forum posts, other solutions that I would be able to open, save to the full one for real use. May be I will see the beauty of VIs in new versions and agree to upgrade 😃



Is it possible that the contents within the instr.lib to be defaulted to read-only every time LabVIEW launches? VIs that is drag-drop from the pallet onto block diagram is currently modifiable and may cause unintentional code modifications, especially due to the 'save all' function and hasty/improper shutdown. The extend of the damage may be inherited over time.


Also propose to default modified instr.lib VIs saves to be in active project folder instead of the instr.lib.


Hope to see these features in future versions.

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

The purpose of this is the user saves time creating installers  that have the same application but theirs configuration files are different.

Please can the installer be changed to stop using removable drives as a temporary location for installation files. I had a 2TB drive attached when I started the install and "safely removed" it part way through. The install then failed Smiley Frustrated

I assume it uses the largest attached drive available. If possible could it check for the fastest drive instead. My main drive is an SSD with an HDD as the secondary drive which is larger. The SSD would have been the best choice in this instance.


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.



The package manager for Windows (like apt-get but for Windows).


Chocolatey it's a command line tool to download and install software with focus in automation and unattended..


something like:


choco install labview


and after a few coffees, voila. All installed.


it also supports local files, e.g.


choco install labview --source d:\


in case you have the "package" in the d drive.



Installing NI drivers should be something like:


 choco install NIDrivers               //full installation



choco install NIDrivers.NIDCPower            // Only NIDCPower 


Toolkits could be handle in the same way.


Chocolatey also handles dependencies. So requiring LV before installing any toolkit should be straight forward.



Make it easier to find the right product in the uninstaller

If you install a lot of National Instruments developer tools the uninstaller becomes very crowded. You can have 50-100 components, often with similar names and varying name structure. Finding the component you want to uninstall/modify/repair can be difficult. 


The fact that things a split into so many separate components is practical, but the components should be organized better:

They could be:

  • logically grouped
  • have descriptions
  • there could be a search/filter function available (that accepts wildcards)

Allow us to specify a new source location

If I want to repair or modify an installation it might turn out that the original source for the installation is gone, or I have a new (identical/compatible) source that I would like to use instead. It would be nice if the uninstaller handled this, instead of insisting on the original. 


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.

How often do you find the need to orginize data into a table format while documenting your vi?  I for one, could & would use it all the time!  Creating a resizable table free label we all use in word & excel seems like a simple task and would aid in organizing and documenting data into a more readable format.  A ctrl+double-click or shift+double-click could serve as an easy access method, tab through the contents, and resize rows and colulmns vis a cursor change while hovering at the specific borders.  Free Label, New type, table format, organize data, rows, columns. 


Free Label Table.png

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 install anything (anything!) from NI on a computer that runs windows 8 or newer, you will get bugged by a dialog to disable fast startup. The option is enabled by default, no matter what you install. It will popup with every single install, even minor patches, and even if this option has been intentionally unchecked in the original installation to be patched. If you don't want to disable fast startup, it is a never-ending whack-a-mole of these dialogs. (... but the need to disable fast startup for some scenarios is a more general problem that NI needs to address. It could be a new idea, but I think NI is aware of this problem. It might even be something that Microsoft could address such that devices don't get lost in the scenarios where fast startup causes problems)


This idea is centered around executables that we built and distribute via installers..


While this option (=disabling fast startup) can be useful when certain DAQ hardware is used, it makes absolutely no sense for other LabVIEW programs. Most of my programs don't use any DAQ hardware and it is not reasonable to globally cripple every single computer that has them installed. People tend to click [next] without reading, assuming that the defaults are typically reasonable.


Currently, this install query can be silenced by editing the setup.ini and changing the entry "WinFastStartup=1" to "WinFastStartup=0". I have built dozens of applications over the last few days and it is becoming seriously annoying to constantly remember to do that.


I suggest that the installer builder should get another checkbox that allows us to set that option permanently. Here is how it could look like.



  • Checking that box will give the current experience where the installer asks to disable fast startup. (it could even be checked by default to mimic the current default behavior)
  • Leaving the box unchecked will skip that dialog and will not disable fast startup.


IDEA SUMMARY: Allow us to configure the fast startup dialog from the installer builder tool.



LabVIEW Projects can use an icon in the exe, but not when running in development, and not in the built installer. 


Add to the LabVIEW project to have a property to set a project icon. With the Project icon, when running in development mode, it can use that icon instead of the standard LabVIEW one. Extremely useful when trying to give demos, screen shots to send to customers and building an exe is not working, feasible or designing on the fly. There is a hack you can do using the shell32.dll that on open of any LabVIEW panel, it can rewrite the icon, but then code must be added for any and every panel to show the icon. Also if the window name changes, you have to call the same code again. 


The installer also does not inherit the icon from the executable being installed. Add an option to add an icon to the installer and have it embedded in the setup.exe. Also include the registry setting for DisplayIcon = Icon path to exe or to defined icon. I've currently been able to change the setup.exe icon using the Resource Tuner application ( for $50). It's as simple as changing the IconGroup 128 with your own icon and save the exe. This embeds the icon to show up in Windows Explorer and as the icon when running the installer.


The wrinkle is that the installer does not have any pointer in the Add/Remove list for Windows for the icon. You have to know the ProductID and ProductCode which changes every time you build the installer, as it is in the setup.ini file at the bottom. Going to the 32bit or 64bit registry (depending on what you are installing), you have to add a new string key "DisplayIcon" and it can point to any icon file or the exe using the path.exe,0 to represent what icon to use. The path to the reg key is somthing like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{E851D69F-49EE-4B9C-BAE7-58AB782E801A}\DisplayIcon. I'm currently developing an exe to run after the installation to set the registry key properly. It takes command line arguments for the Product Name (search registry for the GUID), path to icon/exe to set. This way each installer uses the same executable (LabVIEW built) to set the icon in the add/remove list properly. 

Hi All,


Now a day every where cloud computing is bomming. if NI provides the LabVIEW Free online complier. 

people who does't have any setup .they can learn any where through Internet and NI cloud.



This will helps to more people to learn labview beginer  easily.

It should be easier to change the default copyright company in Application Builder.  


I got the following from NI support to change the name of the company that is copyrighting the software.


1. To show the desired hidden folder, you must select Tools>> Folder Options >> View >> Under 'Files and Folders'>> 'Hidden files and folders' >> check the 'Show hidden files, folders, or drives' >> Select 'ok'

2. Navigate to C:\ProgramData

3. Open ProgramData >> National Instruments >> LVProductDLLInfo >> 12.0.0 >>LabVIEW_ADE_120000.ini   ***Please note that the folder 12.0.0 may instead be 14.1.0 or another numeric value based on which version of LabVIEW you are using***

4. Change the RegisteredOrganization and RegisteredOwner to the appropriate organization and owner respectively.

The fix NI support sent me was to change the name of the current software owner.


The company that owns the software is usually writing the program for another company that is paying to have it developed. If the software owner is not careful they may assign the copyright to their company or to the company that they developed software for last.   I am sure that the company that had software developed will be surprised if their name is not listed as the legal copyright owner.



LabView uses the "primary" MAC address to identify a machine. If the MAC address changes, LabView assumes the software no longer has a valid activation and displays the following:




Like many developers, I have to use a VPN to connect to a corporate network. My VPN client creates a pseudo-interface with a (random?) MAC address each time I connect. LabView inspects this MAC address and decides I've installed LabView on a new machine, forcing me to go through the activation process again. I have to activate LabView about every 10 days. I have contacted support about this, and they have given me various work-arounds such as non-expiring activation codes (which required manually entering 10 activation codes, one per product, and only work until the next LabView service pack), or tying activation to the Disk Volume ID, which frankly I did not bother trying since the "eligibility on a case by case basis" did not mesh with the reality that every point release of LabView requires re-activation.


Now, I don't want to make too much of this. I've never had the activation fail, and it is pretty fast, so it's really not a big deal, but it is kind of silly to identify a machine based on a mutable property. Heck, on linux it's trivial to change the MAC address to anything you want! (I tried this with my VPN client, but it had none of it.)


I suggest the activation process something more stable, like the CPUID on Intel processors or, barring that, restricting the MAC address search to physical interfaces.


Thank you!


Rob Calhoun

NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.


I suggest that NI start shipping USB keys instead. USB has several advantages:


  • USBs are smaller
  • USBs are more usable on devices without DVD player
  • Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
  • USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.


Ship developer suite on NI USB keys