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!
Top Authors
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

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.

When you install LabVIEW and MAX configuration support for DAQmx (and other components are the same) the NI Package Manager adds a number of other LabVIEW runtime versions to the list of dependencies.

When I install support for LabVIEW 2019, the package manager add LabVIEW 2014 and 2018 runtimes.


Surely this can be tidied up!  Please tidy up dependencies.


If I only have LabVIEW 2019 installed on my system, I shouldn't need the LabVIEW 2014 and 2018 runtimes to make a 2019 component work.

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?


  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

This suggestion has been made before twice, in 2010 and 2011, in a more or less similar manner, and declined both times, but in light of the recent announcement of LabVIEW Community Edition I thought it might be worth a 3rd shot, so here it is with my own rationale for it (originally posted here).


Consider eventually also making available an (also free) "Core" edition of LabVIEW coupled with a much-reduced-in-size "LabVIEW Core Runtime", with everything hardware- and advanced-math-related removed, but allowing for commercial and academic usage.


There would be many benefits in doing so:


  1. It'd would allow LabVIEW to develop more into general purpose language, suitable for developing generic cross-platform desktop and web applications;
  2. It'd bring all manners of new developers from outside the very specialized field of industrial applications;
  3. These non-industrially-focused developer would develop new libraries and open source packages that'd expand LabVIEW's capabilities in all manners of directions;
  4. And then all these elements -- 3rd party "for core" tools, new developers, new ideas -- would provide a boost to the industrial-related versions, which would become the natural upgrade paths.

Doing this might risk losing a few sales of paid-for versions, and it'd also incur in costs as NI would have to decouple many things, which would require lots of engineering hours to do. But I believe long term it'd boost LabVIEW's usage in significant ways, and result into even more sales down the line.


Typical usage progressions would become something like this:


  • Core → Community → Base → Full → Pro → Pro + add-ons → Suite(s)
  • Core → Core + (new, paid for) Advanced Math and similar core-focused add-ons → etc.
  • Core for entry level generic programming classes → Academic licenses for classes focused on industrial applications → Academic licenses for actual research

And so on and so forth.


Please consider it, okay? 🙂

For all of the work the knights of the forum do, I propose that upon retirement they receive a lifetime license to LabVIEW.

  1. They deserve it.
  2. Their help on the forums for other users cannot be quantified. 

Not sure where I read it on the forums, but I think it stinks that @Ben needs to wait until the community edition is released to have a working copy of LabVIEW.



I think it is useful if the installer automatically 'Force Re-install' if the same software has been already installed with the computer. This will omit the procedure to kick-start force re-installation via command prompt, some users may not be familiar with.



force reinstallation.png

It would be helpful to have Refresh Palettes operation as part of the built-in Command Line Operations. This would help fill in the NI Package's short coming of not having palette tools like VI Package Manager. My suggestion is the Operation Name to be RefreshPalettes and require any additional arguments.

It would help to have an option to ignore Bad VIs errors when calling a mass compile via LabVIEWCLI. This makes the CLI MassCompile unusable for deploying code with NI Package Manager that has API Tree VI. It would help to have an option to ignore those errors so that NI Package custom execute could run successfully. I would think it could be defined as optional argument. My suggestion for the argument is -IgnoreBadVIs true|false with a default of false.

Hello forum


Wouldn't it be nice if we can add W10 IoT Enterprise PCs as Embedded Targets, where we can create VI executable and set it as startup programs and once deployed, the target will be automatically configured to: launch the startup programs with Embedded Enabling Features (EEF), Enhanced Write Filter (EWF), Hibernate Once, Resume Many (HORM) and File Based Write Filter (FBWF) but on different volume; as presented in NI Week TS2361 & TS8562 slides.



When installing recent updates for LabVIEW 2018 an error message came up that said the installer needs access to "My Documents". However this location "file path" is not available.  My company has a drive mapping package that has the my documents located on the server as well as my favorites so it is automatically backed up for recovery purposes.  The installer keeps getting this error and forums state that the IT admins need to get involved every time to update & set my documents to local temporarily to install, then back to the server for automatic backups.  This is very tedious and takes a lot of manpower.  My colleague has the same issue with DIAdem 2018 as well.  Looking to possibly have a fix where it gives the user a browse option to find the file path it needs for the install.  

hello forum


what do you think about a "feature" where developers can enforce version control on applications deployed into end-user systems? it may sound something like some feature of a certain OS, but it may be beneficial in a way or two...


the most obvious being for version enforcement, some members may not like this, but often time newer versions of application are developed to address certain issues of the previous version, and it would be pointless if the end user kept sticking to the old version for certain feature they may have grown to like


it can also be extended to subscription based or trial version deployments, a more friendly way for developers to present their systems for customers for in-situ system trial


one way to deploy this feature, is to minimally trace the execution instances of the RTE in deployed systems, across newer and older version, log them for follow-up actions, that can range from friendly popup reminders for update to application execution prevention.


what do you think?

We like to keep the OS installation clean/stock.  That is, install RHEL and any packages required for the engineering applications and try to keep the installation packages to the minimum that are required.  Typically the EDA vendors will have a script that checks that all of the Linux package required the application.  If we find any dependencies we install on all machines.  The LabView Linux installation script wants to be run as root and install packages.  Would rather see a dependency check script so that we can install the dependencies ourselves and know what is being installed. 


For the application tool itself we don't want to install in /usr/local on all machines but rather install into a NFS mounted file server so that we only need to install once and not install on each machine individually.  The current Linux installation script doesn't take an argument to specify an installation directory other than /usr/local.

<bakground>So i just had a silly thing happen to me, i compiled a program and deployed it to the target computer, just like i did yesterday. Then it started complaining about a missing LV 2017 Runtime ... How? Why?

I reinstalled, repaired and it didn't help, both program and RT, several times and it didn't help.

I tested another program which started just fine, so what's missing? Is it some sub-package that my custom RT-installer didn't include?

I called NI and the support technician couldn't see anything wrong either, so with him on the phone i went to the development computer to look at some installer settings he had dug up. That's when i noticed i was in LV2017 64 bit! The messages said nothing about that! </background>



Improve error messaging when missing RunTime. Include the bitness that's missing, now it only said "Missing LabVIEW RunTime 2017", if it had said "Missing LabVIEW RunTime 2017 (64 bit)" i would have reacted and understood directly, now it cost way too much time to admit. 😕


Also, isn't it time to scrap the 32 bit version and go only 64? 🙂


For all of us not running an english OS but want to install plain english versions of NI products:

Please give us an option or a documented method to install LabVIEW and  MAX and driver, etc. in plain english.

While it is possible to install LabVIEW in ENG, the MAX and the driver installer lookup the OS language and install the localized versions 😞   (just tried with a new PC, W10 and LV2018 full dev suite, even set my language setting to ENG, however I have to install the localized W10)  That is not helpfull if you want to look up the big commuinty help or knowledge base entries and can result in 'funny' error messages.


For the driver DVD I think I found a hack in the setup.ini

[Localization] Languages=9,7,12,17,18,2052 #ForceLanguage = 9 CustomRes0009=SupportFiles\resourceEng.dll CustomRes0007=SupportFiles\resourceDeu.dll CustomRes0012=SupportFiles\resourceFra.dll CustomRes0017=SupportFiles\resourceJpn.dll CustomRes0018=SupportFiles\resourceKor.dll CustomRes2052=SupportFiles\resourceChs.dll StandardRes0007=SupportFiles\niresdeu.dll

by uncommenting the red part. But editing the setup.ini ??

OK, in this case the hint was there (or forgotten to remove :D)

The actual suite installer comes with a .xml  configuration file where that hint was missing or overseen.


I suggest something like:


Installer found local language version: <OsLang> ,

Install (where possible) in language: <ListOfSupportedLanguages>


That setting is hopefully stored for future automatic updates 😉

This has been a problem since LV 2018 beta.  LabVIEW deactivates for no apparent reason; and it's gotten worse and worse as the year has progressed.  I now must reactivate LabVIEW every time I start it (your product support seems to be clueless).

My idea is that you design a Licensing/Activation system that behaves in a sane manner.

It might be worth exploring the feasibility of having an online vi upgrade/downgrade service, where you could submit your vi, and receive back the new vi.


I realize this wold be a huge undertaking, however, a reasonable fee could be charged. It could be a second option, in case the customer:

Has tried to do this on their own and failed

Does not have the intermediate versions to perform the required jumps

Isn't worth their time considering the cost of the service


In the case of upgrading a vi, this could serve as an added incentive to invest in the latest version of Labview, especially if the customer is several versions behind.

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.


Morning forum


Propose to have RAD utility to include a "Snapshot/Clone" function that snap the image "exactly as is" the state of the cRIO/PAC at that image creation instance; that would include the entire drive structure, configurations, bit files, network settings, etc. Restoring from such type of image onto the cRIO will, without fail, guarantees its functionality (at least back to the state the image is created).


This come after the 2nd time of suspected corruption, when I deployed with error in LV causing irreversible/permanent impairment to my deployed RT application. First time being without a backup, that led me to reformat, reinstall and redeploy for one mistake in deployment. Second time being with a backup, apparently incomplete image using the RAD16 (, upon deployment failure and image restoration, the damage has not been reversed.


Hopefully to see this option developed soon, as the conventionally advised method of reformatting, reinstalling and redeploying cRIO, is not really practical.


Thanks and have a great day...

I faced issues while creating an installer with a size of 2GB+. Unfortunately I had to upload the installer to a shared site that didn't accept files > 400MB. The want for a separate installer and process thereof delayed my delivery.

I remember from other software(s) having distro creation capabilities in size of lets say a standard CD size of 650MB, etc.

Wouldn't it help many if the app builder allowed splitting the installer in a defined packet size?


How about an NXG home edition, so folks can try it without any heavy time or cash commitment. It would help acceptance and uptake in the LabView community.