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.

In LabVIEW we can specify <topvi> as a VI search path when VIs can't be found.


I would propose adding <project> as an option (perhaps with a subfolder by default). This would allow for new reuse patterns based on keeping libraries in the project. I expect this would make tools like GPM much easier to develop as well.


It could be a first step to something like node_modules in NPM or virtual environments in Python.




So I'm going through a bunch of VIs and relinking them.  So I go to a folder and select say 100 VIs and drop them into a new blank VI.  A bunch of dialogs come up telling me VIs are missing and I ignore them all at the moment.  Then I go to the block diagram to find which ones are broken to review them one at a time.  The only problem is the error list window displays over 100 errors that aren't "SubVI is not Executable".  I have all kinds of errors about required inputs not being wired, and for "This VI cannot access the referenced item in private scope".  Well I don't really care I'm not trying to run these I'm just trying to find all broken VIs and fix them.


Which got me thinking, can we have a category view of some kind in the Error List Window?


Required input not wired.pngSubVI not executable.png

The variant data type parsing palette is great when you have to deal with passing variants around. However, there is one call that would be super useful. If I have two variants, I'd like to know if they are of the exact same type. The type information only tells you so much. For example, if you have an array in the variant, it will only tell you it's an array, not a double float array, or a waveform array.


I've wrote a version of this that does it, but I'm not sure I cover all the edge cases. NI would be much better suited to ensure it covers all the potential typing possible and can likely make it more efficient than I could. But, I think this implementation solves this issue for most common data types and even some more exotic things that could be in a variant. I would love to see this included in the variant data type parsing palette.

Screen Shot 2020-08-13 at 8.56.41 AM.png

In this example, I'm using it to check an array of variants to filter out ones of type I32.

Hi folks,


While disconnecting terminals, the amount of context menu selections can be cumbersome.

I'd like to propose that for disconnecting a terminal it'd be nice just hold down ALT or another key, followed by a left click to disconnect a terminal.


That would save users from repeatedly doing this:

Disconnect this Terminal.png


Thank you,


Mr. Jim


The mother of all diagrams, the Block Diagram, does not have a subdiagram label...



subdiagram label.png


Almost every time I work on a new test system and start documenting, I can't tell which drivers, add-ons... the code depends on.

The documentation (design description) should at a minimum tell a new developer what drivers, add-ons... must be installed to have the code executable on a development machine.

I've issued a support request on this, but the support team told me that there are no such funtionality in LabVIEW. The Dependencies folder in the project gives you some indications. VI Hierarchy and VI Analyzer also give some indications. The only way to sort this out is to install LabVIEW stripped from all extras and then install one driver/add-on... at a time until your code gets executable.


My suggestion is that the LabVIEW development environment is equipped with a functionality where the drivers, add-ons... required for your code can be shown.

A simple request - Close Zip File should return the file path, in the same way that other file closing VIs do.


I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.


To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.

A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:




In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.

A big project can take more than 10 minutes to load, especially on an older computer.  If subVIs are missing, the Ignore Item and Ignore All buttons become available when the first VI is missing.  This can happen anytime during the loading and the process stops until the browse box is canceled and then the Ignore All button is pressed. 


It would be better if the Ignore All button was always available where it can be clicked at the beginning to insure the project is loaded in the expected time.

Ignore All.png



  It would be very usefull to know which VIs are still running.


I like the "new" Review and Update Typedef feature.


What I don't like is handling the CASE structures I have connected to enums when the enums update. The constants for the enums update fine, but the selectors for the CASE structure are not included in this operation.  I really wish these could be handled as pseudo-constants for enums, allowing re-assignment of cases with a preview of old and new values.  I've started adding an enum constant to each case just to serve as a reminder which case it's actually supposed to be. And that feels kludgy.


Currently, case structures auto-adapt to enum indices. I'd like that to no longer be the case.

Under Web Services there is a conversion palette.  One of the functions here is to convert LV Image data to a PNG stream.  This is super useful when dealing with sending and receiving large amounts of PNG data over something like websockets.  I've used this in places where a web page can control a VI, and the image of some front panel controls can be sent to the web page.


However only recently did I realize this function turns the image into a PNG stream that is completely uncompressed.  This idea is to expose the Compression input to the VI.  Here is just one example where I get the image of a control then represent it as a PNG.  With no compression this file is over 64KB.  With just the most minimum compression that drops to 3KB, and down to 2KB under the highest compression.





When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:




Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:




To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):




The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.




Just as for Clusters, I would like to be able to change a Map constant on the Block Diagram to be viewable as an Icon when it has been made a TypeDef.  You can't directly edit the constant data, so for me it doesn't make it worth the large amount of real estate that it can take up, especially if you have a Map of Maps/Sets.

So for example, instead of this:

I would like:


Related to Darren's (implemented in 2014) idea here, Include LabVIEW Version Number in Application Icon, I'd like to ask if the number could be a bit bigger, perhaps as an alternative icon found in the LabVIEW.exe.


If I browse for possible icons (without providing my own file), I see these options:


The first (default) icon is great, but on a 4k monitor without DPI scaling, it can be a bit tricky to read on the taskbar (that 19 is pretty small).


Could an alternative icon (not the default) be provided with a larger number, taking up more of the total space?

I'm working on several large LabVIEW projects and I'm using GIT.

GIT creates a hidden folder named ".git" within the repository root path which usually also the LV projects root path. All the different file versions are stored there.This leads to the situation that the number of files within the .git folder is much higher than the number of files which are directly used by the LabVIEW project.


If LabVIEW is missing a file or if a mass compilation is started in the project root, LabVIEW searches also within this hidden .git folder which leads to much much longer processing times.


There are several possibilities to change the behavior in an appropriate way:

1) ignoring hidden folders in general

2) ignoring .git and other special folders automatically

3) ignoring folders (and files) if they have been set to a blacklist before (how about a ".lvignore" file similar to ".gitignore"?)



If you change the comparison function "Is Path and Not" to a malleable VI, then it will be able to accept arrays of paths.

LabVIEW 2020 allows you to remove the event property nodes shown here:


It's a nice feature because these nodes are often not used and can get in the way.  However -- the process for removing them is a bit tedious: you have to either remove them all individually or size the cluster down to one and then remove through a menu.  I find that I rarely use this because, well, it just takes too long.


However...if you could just click on the node (it's already selectable) and then click the "delete" button on your keyboard, this process would be near-instantaneous, and I know I'd be much more likely to use it.


                                            "Build Path" should be Growable


                              something like this,