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

I am quite often encountering the issue, when I remove an item from project, however, that item still remains on disc. This can cause various issues. Files can be of course deleted manually or when switching to Files view in project explorer, but I seem to always forget that. It would be nice to have another option in project explorer, which would also remove the file on disc (after dialog with confirmation, so that we dont delete files accidentally)

0 Kudos

In Java, any errors/exceptions that a function can throw (to its caller) are listed directly in its signature/declaration.  This would be nice functionality to have in LabVIEW.  Otherwise, the only way to determine which errors a VI can return is to either:

  • examine the code manually, recursing through all its subVIs or
  • brute-force exercise the VI until you have observed all errors that it might throw in your particular application. 

Neither of these options seems particularly robust or efficient.


It may even be possible for LabVIEW to determine the throwable errors automatically, although at least having the ability to declare them manually would be a good start.  They could be registered through the development environment such that they are stored in the VI file itself.  In this way LabVIEW could summarize all the errors a given VI throws based on those declared within it and its subVIs. I acknowledge that this would likely require a more sophisticated error system than the current error codes (since these may not be known at compile time).  But, I would be surprised if it couldn't be achieved in a similar fashion to Java where all errors are classes that inherit from a common "error" class.


If I'm missing some methodical, pragmatic approach for achieving the same result, please let me know.

Currently, when you use context help and hover over a VI it shows terminals and a little snippet of what it does. I use this a lot. When using quick drop though, the context help doesnt dynamically change to each item selected or hovered over with the mouse. Its like this currently



I would like to see it so that when I hover over an item in the quick drop, the help page updates so I can read it without having to drop it onto my back panel, read, then delete and try again. Like this



0 Kudos

The function "in the range" has as a boolean output. I propose to replace it with an enum that would indicate which limit has been exceeded.


0 Kudos


0 Kudos

There are keyboard shortcuts with fairly universal adoption that LabVIEW does not utilize, but would be helpful. Two of these are:

  1. Shift + scroll wheel: for side scrolling in front panels or block diagrams. (And yes, this is useful in many situations that do not involve over-sized diagrams.)
  2. F2: for editing text content, i.e. of a selected label, comment, etc.

0 Kudos

So, in some inherited code there's lots of Compound Arithmetics where the input wires are either random or reversed from a neatness perspective.

It seems the Ctrl+click switcheroo only works on the 2 input version, and it'd be good if it worked on the larger ones. The way I see it work is either:

1. Hover over the input separator to switch those two specific inputs, which'd make a full reversal a sort of manual Bubblesort

2. Like the VI input selector, where you can select one and Ctrl+click another to switch those two.


(Atleast I cannot seem to do it in LV2017)



CTRL+Click on an input is a great little tool to switch the input.


However, it only works when both inputs are wired. Often (, I or QD connected a wire wrong,) I feel like switching the input, before wire-ing the 2nd. Only to find it doesn't work...


Having to connect the 2nd wire just seems to disrupt the flow, being focused on the first input. Being forced to make things worse (connect two wrong wires) before being able to make it right just feels itchy to me.

Switch one wire.png


It's a minor thing, but I never understood why it would be limited to 2 wires.

0 Kudos

Quite frequently, I encounter a need to do something repetitive on clusters, which have identical elements. Sometimes, I use "Cluster to array" and then "Array to cluster" vi's, like in the example below:

For loop on cluster.PNG


Instead of doing this, I would like to use a kind of "For loop", which would be able to operate directly on clusters with identical elements. The loop would iterate already during the compilation (generating repetitive code for each cluster element).


Perhaps, the standard For loop connector might have something like an option "Iterate over cluster elements".

0 Kudos

That would be usefull to elimimate all the files needed by a polymorphic VI and would also be useful in malleable VIMs where a portion of the code is needed in multiple cases but will or should never be used outside of the VIM.

0 Kudos

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.

Add a new button to the search results dialog called "Set Aside" so I can have multiple search results open at the same time.  Put it near the bottom just below the search results.  When you click it, it changes the title of the window to "Search Results - Set Aside 1".  If you click "Set Aside" again when #1 is open, it will open "Search Results - Set Aside 2" ... and so on.  This way you can have several different search results open simultaneously.  I love the check mark feature in the search results, but it resets every time the search windows is closed or overwritten by a new search.  Thus I lose my place if I want to make sure to check every instance of something but need to search again while looking at one item.

0 Kudos

Just upgraded to 2018 and found that all the icons in the palettes, toolbars, etc. now have a wider border. "Nice"... Now that breaks all my mouse macros that I had build to make up for the forever missing keyboard shortcuts that NI never has time to work on (because is working in "features" like making wider borders on icons).


NI had time to mess with toolbar icon borders, but STILL didn't put toolbar icons to save the current VI, Save All VIs, etc.Smiley Frustrated

When developing a Complex LabVIEW Applications, we may need to create N Number of Folders as a part of Configuration information.

This requires the developer to make a check "Check if File or Folder Exists"

Instead of that Create Folder Function can have a Boolean "Optional Input" to create the Folder only if not found in the specified Location and Eliminating the Error when trying to create same folder again.

Hope this will help Smiley Happy

0 Kudos

Originally, I asked this query on NI discussion forum Retain Default Data Type of Input Terminal in VI . Thanks @GerdW and @crossrulz to encourage me to share this on IdeaExchange. I need such functionality in one of my project.  


When I take Open VI Reference function and create a constant for Option input terminal it shows Numeric constant with HEX radix (Default). So to add same functionality in I put numeric control on front panel with display format set to HEX. But when creating a constant to this input terminal the default data type is DEC and does not show HEX radix likewise in Open VI Reference function. I also tried by making Numeric control strict typedef but didn't work. So how to do this?

Below are the screenshots for same.






A right click option for each auto indexed array that allows will not use the length of that array in choosing the number of iterations. If there is no input to the count terminal all auto-indexed terminals can go beyond their length otherwise at least one must remain as a driver for determining the length. If multiple are left with the default (existing) behavior, the shortest length will be used. For any iteration where the array is shorter that the "i" of the loop, the defaults for the data type will be returned (just as if "index array" blocks had been used inside the loop. 


Similarly the loop could be set to use the longest array instead of the shortest.


Additionally a similar function could be done when any array compare or math functions are done. In the case of compare functions if set to use longest array, the result will be false for any compare to an empty element of the shorter array, and math functions will use the default data type for empty elements.

0 Kudos

It would be necessary to insert an alert when opening .vis made with different versions of LabVIEW than the latest used. "This file has been created with LabVIEW 13. Current version is LabVIEW 15. Do you want to open?" Y/N I work with at least 4 different versions of LabVIEW and sometimes happens to open a project (and to work on it for hours....) with another LabVIEW version, without noticing the automatic upgrade. Then time for downgrading again. Thanks

0 Kudos

Right-clicking objects on the block diagram in LabVIEW produces a shortcut menu appears. When placed on replace, a menu is shown that is sensitive to the selected item and the option to access all the palettes. Often, when we want to replace an element, we also want to use some other element from the same palette.




When we access the palette, the thumb tack pins are missing, and if we need to access more than one element, it is necessary to navigate in the block diagram through the functions palette. In addition, when we get used to using the "Quick drop", when we need to access items that we don't normally use, it is difficult to locate on the paletta, so I propose, include in the palette from shortcut menu the thumb tack pins.

0 Kudos

Currently, we can make inputs to subVIs optional (or indeed recommended) and not wire them - in this case, the default value for the input terminal is used. By default, this is the default value for the type, but it can be easily changed to another value (at least for terminals you can easily set).


Since there is no "optional" type, this leads to code potentially like


If -1 is always an invalid value here, this might not be so terrible. The issue becomes more pervasive with, for example, empty strings (or string constants) when an empty string or that constant might conceivably be a valid value.


Class objects could be an additional problem, especially if a hierarchy is considered, because you might want to wire an uninitialized child object to an Init Object method, and it would fail an equality check vs the terminal type. You might then mistakenly conclude that it was already partially/fully initialized, and carry out the incorrect processing (in this exact case, probably dynamic dispatch followed by an equality check against the specific child, then calls to a static dispatch "Init" in the parent might work).


We can work around this if needed by using a boolean clustered with the value, and then checking the boolean, but this makes wiring the subVI and creating its inputs more frustrating.


I would like to see an optional terminal type that could be checked using a primitive to indicate if it was wired by the caller or not.


(Apologies for the ugly icon, and probably dubious naming)



For the draft of the proposing paper in C++ for the std::​optional type, see

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.