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

When you open a VI which includes add-on libraries and/or toolkits, LabVIEW will detect them and suggest installing for users!


This will be helpful if the user does not know much about NI software.


Install Suggestion.png



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"





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.

When you run the LabVIEW Platform DVD, the default setting is that LabVIEW gets installed and nothing else. You can then go pick and choose what modules and toolkits to install. I like this default because I usually only want to install LabVIEW and a few other modules and toolkits. It is faster for me to select the few modules that I want to install rather than unchecking all of the modules I don't want to install.


When you run the Device Drivers DVD, it tries to guess what drivers you want installed based on the software you already have installed. However, it usually wants to install more drivers than I want it to install. It is a hassle to go through the driver list and unclick the drivers I don't want to install because most of them have dependencies that you have to unclick first. 


Idea: Their should be a button on the Device Drivers installation screen to unselect all of the drivers (see image below). I don't think the Device Drivers DVD default should be the same as the Platform DVD; a lot of new users won't know what drivers they need and installing all of the recommended drivers is a safe bet. However, many users do know what drivers they want and it saves time and hard drive space to only install the necessary drivers. Adding an "uncheck all" button would make this process faster and less frustrating.


device drivers.png

Add an "Uncheck All" button!

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...


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.

I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".  

I know there are others out there like me, I HATE upgrading Labview.  All the time required to update your custom configuration takes weeks.  Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.


Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software.  For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.


My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV.  Making the upgrade process easier with a single tool.

Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade.  If it was more seamless to upgrade, I'd probably upgrade every release!  


Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.


Perhaps NI should accumulate all of these requests to Upgrade and total them as one.  Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.


Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.


There is a logical glitch in the App.Version property; If you read App.Name you get the name of the built application...but if you read App.Version it's not the version of the application - it's the version of the RTE.


I use the application version in splash screens etc. - however today I have to manually write this multiple places because I cannot read the version number I used when building the application.




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



If someone would have asked if there was a setting to run a VI after an installer was build I would have said yes, until today when I realized I needed it and couldn't find it.  When building an EXE there is a Pre/Post Build Actions section where you can specify a VI to be ran before the build or after it.  But this appears to be limited to building EXEs and not installers.  There are several limitations to the NI building process, and I'd like to improve them by having functions get ran after a build of an installer is complete.



EXE settings

EXE Builder Settings.png



Installer Settings

Installer Settings.png



Could it be possible for LabVIEW (even if only for versions 202{1,2,3} onwards etc) to make an attempt to open newer files and just break them when new features are used?


The comments in this Idea (LabVIEW Compatibility Modes) suggest this and related ideas, but it isn't the main part of that idea, so I'm posting it separately here.


An ideal solution for me would be for VIs to automatically save back in the 'oldest' version that they would support (and perhaps not be 'up-compiled' on load), but this idea has been discussed a few times and doesn't appear to be something NI will support.


An alternative (perhaps only possible in currently unreleased versions?) might be to have LabVIEW 202x try and open a VI saved in 202<x+n>, and then give the symbol for missing VIs (ideally with the name, if possible) for anything that isn't supported.


As an example, trying to open a VI using Insert into Map (if this were available for existing LabVIEW versions) in LabVIEW 2018 could produce something like


with the Context Help giving me a clue as to what was lost - I could then Google "Insert into Map LabVIEW" and try guess how I might replace it (here, probably with Variant Attributes).


I'm posting this idea in relation to some comments I've recently heard regarding sharing and packaging code with LabVIEW, and how even when other (text) languages add new features and so code using them will fail to compile, their users/developers can still open the code, try fix bits, or generally workaround issues (and evaluate the benefits of upgrading, if the changes are large).

New versions of LabVIEW continue to have significant new features, so upgrading seems like it will continue to be at least my preference, but not everyone has the same requirements/situation/SSP/blah blah blah.

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

Delete option in Context Menu.png

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is uncomfortable.


So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past...:smileyhappy: He! He! He!

This idea is about a new LabVIEW feature, the Packed Project Library.


To statically use a packed library as a dependency, you need to add the library to the LabVIEW project.  After that's done, all the callers link to the packed library.  If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.


But what happens if you're a packed library user and developer of the same library.  You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.


If you're a user and developer, it makes sense (to me) to maintain two separate projects.  One manages the packed library resource, one manages the application.


What if there were a way to revert the packed library to the LabVIEW library from the same project?  You could use the spiral development model and simply switch between the two types of libraries during development.  You could also (and this IMHO is the most important part) incrementally deploy and test the project.  If you're strictly a packed library developer, hopefully you're incrementally testing anyway.


My final pain point with the packed library is with respect to upgrading the application.  Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade.  If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp.  Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself.  I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).


This leads me to a best-practice for lvlibp: always use them as dynamic dependencies.  That way, you can maintain and develop the packed library in the same project that uses the packed library.  You'll simply reference the resources differently.


Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.





I downloaded LabVIEW from and installed it.  Here's the process:


  1) Download a small downloader using my web browser.
  2) Run the downloader, which then downloads a self-extracter
  3) Run the self-extracter, which extracts the installer
  4) Run the installer


I'm thinking that this process can be improved a little.

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

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.

If LV can create .exe file independent to LV runtime engine, that's will make her more pretty than other programing tools(e.g VC++) 

I propose that NI award anyone who posts an idea (especially this one) which is eventually accepted receive a free copy of the LabVIEW Developer Suite as an award for their creativity.


Should help find duplicates!

This is only a wish that NI could provide a Utility that converts a VI or Dir to Up or Down.

I had a project that was done in LabVIEW 5 (done many years ago by someone else); I couldn’t open in LabVIEW 8.6. I needed to do stage upgrade LabVIEW 7 and follow up with LabVIEW 8.6 and so on.

I understand there are cases that you can not simply down convert, because newer function may not be available in older version. In this case it OK, give user an option for force the convert and worse case the down convert VI is broken. Let the programmer fix it!

The utility should have a Status Report for convention.