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 installed LabVIEW 2020 on my PC and my friend is working with LabVIEW 2016 every time I open his projekt now it gets upconverted and if I downconvert it to 2016 I can only do it via the special option, which does not even allow me to overwrite the original 2016 files. Iam stuck with 2020 since I did not buy SSP GREAT, how is this in any way userfriendly? Its worse then the compatibility of Word with Libre office.


That was Bryans original post 12 years ago, its still the same.



Many of us have to install multiple versions of LabVIEW on a development system due to legacy projects where the benefits of transfer to newer versions of LabVIEW are outweighed by time and risk.


What I'd like to be able to do is have modern versions of drivers etc installed at the same time as legacy ones that are unsupported.


For instance, I have IMAQdx installed for LV2019 and LV2016 using VAS 19.5, which is only backwards compatible down to LV2016 (ref). I'm trying to install IMAQdx 4.2 to be able to use it as part of an LV2013 installation, but the installer will always tell me that there's no need, I've got a newer version! Unfortunately, said newer version isn't compatible with LV2013.


My workaround is to uninstall IMAQdx and IMAQ 19.5, install 4.2, then deal with the consequences afterwards. The other alternative would be to set up a series of VMs for different versions, but that's easier said than done in my company!

Trying to toggle back and forth between the instructions and the code for the online CLD exam was both distracting and difficult since most hot keys didn't work. Placing the instructions or goals in the block diagram would allow easier reference for those taking the exam. 


Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.



I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.

Consolidate all LabVIEW G files into two file extensions:

  • Source LabVIEW File (*.xx) - Human readable source code files (e.g. *.vi)
  • Compiled LabVIEW File (*.xxc) - Compressed compiled binary files (e.g. *.vic) 


LabVIEW is proprietary. I need LabVIEW to open LabVIEW files. There are +15 LabVIEW file extensions to create LabVIEW G code. Recognizable LabVIEW extensions are worthless because I still need LabVIEW to open and edit the files. Some LabVIEW files contain compiled code, whereas other LabVIEW files are glorified name-spacers; some are UI components, while others embed compiled LabVIEW code into other LabVIEW files.


With every new LabVIEW version, capabilities are added that inherently cause inconsistencies between LabVIEW file types, environments and overall behavior. Let me explain. 



  1. Current LabVIEW file types don't adhere to consistent behavior:
    • Libraries (lvlib, lvclass, xnode, xctl) are xml files (human readable) but also contain encoded compressed data (non-human readable)
    • VIs (vi, vit, vim, ctl, ctt) are binary files that can contain compiled code (or not)
    • Libraries (lvclass) add dynamic capabilities like dynamically dispatched VIs and can embed class private data controls (or not for interfaces) using the same extension, rendering the extension useless
  2. Inconsistent code redistribution
    • Distribution libraries (llb, lvlibp) embed compiled code differently
    • Packed libraries (lvlibp) resolve system paths differently that source
    • Libraries (lvlib, lvclass) lack the capabilities to embed reusable libraries for redistribution - Similar to Python's PIP library
    • Some 3rd party applications (like VIPM) to manage distribution inconsistencies add more file types and compounds the redistribution problem
  3. Compatibility discrepancies
    • VI (Poly, Express), Class (Class, Interface) already introduces development idiosyncrasies that could be resolved with a one "file" fits all methodology.
    • More file extensions equals more variability, increased maintenance time, and puts ownership on developer community to find discrepancies

Proposed Solution:

  1. Consolidate current LabVIEW G source files (vi, vit, vim, ctl, ctt, lvclass, lvlib, xnode, xctl) into a single Source LabVIEW File (*.xx) that is human readable (i.e. xml) that contains no encoded, compiled or compressed data. - Similar to NXG's xml format
  2. Introduce Source LabVIEW File (*.xx) nesting/namespacing to remove the need for external Library files (lvclass, lvlib, xnode, xctl) - Similar to how C# or Python files allow for multiple methods within a single file.
  3. Add a build spec component to generate a Compiled LabVIEW File (*.xxc) that embeds the Source LabVIEW Files and Compiled Object Cache - Similar to Python wheels/pip package manager
  4. Allow developers to use the Source LabVIEW File (*.xx) or Compiled LabVIEW File (*.xxc) interchangeably in their development projects - Similar to how Python's *.py or *.pyc can be called


A single LabVIEW Source File (*.xx)...

  • can be human readable (i.e. xml) - Editor agnostic
  • can embed one or more LabVIEW Source Files - Single file libraries
  • replaces *.vi, *.vit, *.vim, *.ctl, *.ctt, *.lvlib, *.lvclass, *.xnode, *.xctl
  • adheres to common coding language extensions (C#=cs, Python=py, Java=java)

A single LabVIEW Compiled Files (*.xxc)...

  • is a specific build specification for packaging and distribution
  • contains the source files (optional) and compiled object cache
  • can embed run-time components - Package distribution
  • adheres to common coding practices (Python=.pyc, Java=.jar)
  • replaces *.lvlibp, *.llb, [*.exe]


LabVIEW currently has +15 extensions to develop G code:

(Not including, LV Projects, NXG, VeriStand, TestStand, LabWindows/CVI, etc.):

- Virtual Instrument (*.vi)

- Virtual Instrument Template (*.vit)

- Malleable Virtual Instrument (*.vim)

- Control (*.ctl)

- Control Template (*.ctt)

- Virtual Instrument Library (*.llb)

- Library (*.lvlib)

- Class (*.lvclass)

- XNode (*.xnode)

- XControl (*.xctl)

- Packed Library (*.lvlibp)

- Palette Menu (*.mnu)

- Run-Time Menu (*.rtm)

- Data (*.tdm, *.tdms, *.lvm, *.bin3, *.rc)


Should we consolidate?

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.