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

Microsoft introduced a number of restrictions in Vista that makes it more difficult to save program settings and temporary files.


Applications can no longer write to the Program Files directory, but even worse; the common application data directories, like ProgramData and Users\Default  are by default only accessible for writes by administrators and the first user that did the write. Sessions by other users only have read access. The same goes for registry access; the computer keys can not be written by everyone.


As long as it is OK to not share settings between user's you have one good option left; the user's appdata folder. If you do need to share data though - you need to set the access right of the folders you create in the "common" directories. This can currently be achieved e.g. by using a tool like SetACL, however as it has been made a required action now, it should be included in the installer - AND preferably also as VIs on the file and registry (for registry access) palettes.


LabVIEW 2009 introduced one of the tools required to handle the UAC changes - a VI to get the paths of system folders. It should also have a tool to grant access to some of those paths...

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


It is 2011, and everyone is either making the transition to 64bit, or have already done so. Yet LabView on Linux is still stuck in 32bit, and this means that for modern Linux installations you have to install a ton of 32bit support libraries just to run LabView. Not to mention missing out on all the 64bit fun that everyone else enjoys these days, such as access to more memory. Please do something about this.

As of this quarter, the NI developers suite DVDs will only be sent out on a bi-annual basis. See the text in the current Dev Suite donwload site for the text on this (Dev Suite Download Site).


With that in mind, I forsee using the donwload links to get my Dev Suite updates more and more often and using the DVDs less and less.


What I am asking is that a better method be implemented to allow customers to download the software that they need. If you attempt to download any package from the Dev Suite download site, listed above, you must click through between 3 and 4 linked pages to actually arrive at the download link. Given the 46 packages on the page that is a minimum of 138 pages that must be navigated to download Dev Suite.


How about updating the downloader to allow selection of all of the packages you wish to download, press the button and the downloader will take care of getting all of the selected packages.


This downloader should allow download of particular versions of the software (i.e All packages that were released with LV2009 SP1 and the applicable drivers at that time). These should be "presets" that would allow quick identification of which drivers shipped with which version of LV.


Jim Kring had a related post (here), however I think that the two ideas are somewhat different






 Getting a value change event on a shared variables seems to me like something that ought to be expected "out of the box" in LabVIEW.  Polling shared variables for changes is taxing on resources, and such an architecture is generally frowned upon by NI and the LabVIEW community for things like front panel interactions and the like.  Why, then, should we expect to pay extra to deploy applications which such an architecture for interacting with shared variables?


I completely understand the extra license for the DSC run-time, as there are numerous other terrific tools included.  It just seems to me that the SV value change events are one thing that should be freely available for deployment to everyone already paying for the application builder.



According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.


There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.


Smiley Happy

NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:



However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:

Build Error.png


This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.


During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect"  and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.


While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.


The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:

Therefore every time we install a new version of the driver we would need to rename the VI filename within the LLB file.

When I run the installer for my application, I want to display to the user the version of the exe that will be installed.  Since this exe already exists, I should be able to embed a tag in the installer dialog text as a placeholder for this version.  Something like:


This installer will install version %my_exe_version% on your machine.


When the installer is built, the tags are replaced with the actual versions.

This should also work for all components being installed (DLLs, web services, etc)


As a bonus, it would be nice to have access to user defined tags in the build spec that can be embedded into installer dialogs.  Perhaps allowing a prerun VI to populate these so we can invent new ways of adding infomation in the future.  (like accessing user information from the OS and using that to customize the dialogs)

Hi All,


I truly hope this hasn't already been inquired about in some manner, but if it has I'm not even sure what to search for.  Here it goes:


Up until now, I've kept a backup of labview.ini around so that if my computer dies or if I move to a new PC I don't have to spend time reconfiguring options.  It dawned on me tonight that there are a lot of other customizations that LabVIEW developers use.  If heavily relied upon, these customizations can be painful to lose.  For instance:

  • Palette customizations (Including "Place VI Contents" or Merge VIs)
  • user.lib
  • custom icon templates get the idea. (This is a pretty lame list, but it's all I could think of off of the top of my head)


There really ought to be a tool to consolidate all of these options down to the nitpicking details so that they can be exported in the form of a single file. (let's say a zip file, hypothetically)  The user could then access this tool under "Tools-Advanced->Import or Export user settings" or some similar option.


This way, if the user's PC becomes unusable or they are forced by IT department mandate to move to another PC, they could simply import their user setting file and the whole development environment would be configured to their liking, complete with customizations.


Did someone already think of this?







As outlined in a post in the NI forums HERE, and seeing as I'm currently being forced to re-install several LV versions on my Laptop (Have been doing so since yesterday!) I want to re-iterate my affinity for having LV installed in a Virtual PC.


Memory problems, Hard disk crashes, Virii, stupid user: there are many reasons why an OS would need to be re-installed.  In my case it happens that my HDD was on its way out.  I think this may be linked to many crashes I have been experiencing over the last 8-9 months.  I am nor re-installing ALL of my LV versions.  This is a major pain in the tuchas.  I have backups, but I would rather re-install since I don't know when the data corruption started.


Being a nice law-abiding citizen (or a sucker, depends on who you ask) I don't want to violate NI's EULA by installing each LV Version (Ideally each quarterly update)on a separate VM.  This violates rather quickly the "install on 3 PCs rule").


Please please let us install on many Virtual PCs as long as they are not distributed amongst other users.....


Did I say PLEASE?



Just found out MathScript Module does not have a 64-bit version yet. I don't know if NI has any timetable to release its 64bit version?


Why do I need a 64bit version? Mainly the memory issue. I have a Matlab code which requires a massive memory allocation. Now I am trying to use the .m code in LabVIEW, but encountered a 'Not Enough Memory' warning message. I think a 64bit version shuold fix this issue, correct?


Besides, 64bit is the future anyway. So in case MathScript Module 64 bit is not even being considered by NI, I would like to suggest it here.

Our facility runs only one version of labview at a time and that majority of time for installing a new version is spent removing the old version.   A check box on the installer to remove or update the previous version would be a great addition.  In recognizing that several companies must support multiple versions of labview removing the previous version should just be an option, not required. 2nd having the option to select all toolkits and addons to install from the first disk then just a prompt for the other install disks as needed would really speed up the install process as well.

I would like to see future versions install without changing anything in already installed LabVIEW versions. No updates to toolkits, add-ons,  or anything else. After the install, the previous version(s) should work exactly as they did before the new install without any changes. I would also like to be able to install older versions as if there was no newer versions were installed.

A LabVIEW application installer generated from App Builder creates multiple folders and files in the folders. It is desirable to have a single file installer so that customers see only 1 file to install.

When a VI is deprecated in vi.lib or other LabView libraries, please include the word "Deprecated" or some similar, standard word, in the VIs description. When upgrading the LabView version, I can then easily search for any deprecated VIs in my application and can consider rewoking the code to use the replacement VI. 


It would be nice if there were an option for installer build specs that allow the user (who is running the installer) to run the installed application after the installer finishes running.  This would avoid the user having to find the installed application in the Start menu.

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.

At some point the LabVIEW installer stopped asking who I was and what company I work for during the installation process. Instead, the LabVIEW installer assumes that the "Registered Owner" and "Registered Company" of the Windows installation is what should be used.  I'd like it if,

  1. The NI installer stops making this assumption and prompts me for this information.
  2. It was a changeable option in LabVIEW (because changing every registry key doesn't seem to do anything)


When creating an installer for a Labview project it is possible to add Registry keys. But only with type REG_SZ and REG_DWORD.


Make it possible to add keys with other types. Often it is necessary to use the expandable String Type REG_EXPAND_SZ when adding path entries using for example %ProgramFiles% variable.


Add Registry Key page