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



Maybe it would be difficult to implemented it in a user friendly way, but the proposal is related to structures like typical event handlers or state machine handler.  This "typical structure" is a while loop with a couple of shift registers with an included case structure (handling all events or states).  (I know it's not correct what I write, "confusing" an event handler with a case structure, but let me address both with the name "case structure".)

A usual situation is that in most cases, the value of a shift register is "forwarded" from the old value to the new value, except in a couple of cases (where the value changes).

For "output tunnels" in case structure you have the (very useful) option to use the default value (although an optional settable default could be extra useful?).

The idea proposed here is to have an additional option "keep shift register value", so you don't need a lot of wires going from left to right (maybe with some corners to go via the upper or lower part of the diagram).  Of course, a difficulty is that it would be a possibility in the combination of an output tunnel and its connection to a shift register (but I believe LabVIEW can handle already more complex tasks...).

The main goals are:

    - keep case diagrams "clean"

    - focus case diagrams on "changing things"

    - because of the previous two: simplify programming (and formatting - which is sometimes taking time in graphical programming environments).

(If it's not clear, I can try to make a clear example.)

I do this a lot:


I'd rather do this:


I can't find an easy way to edit the value a set constant on a block diagram or event a set control on a front panel.

Currently I do something like this :

edit value of set constantedit value of set constant

The only option from the right clic menu is "empty set"... can't event insert / remove like in an array 😞

The right click, find options are great but limited. I would like to find events that are triggered by a given control/indicator; this is hard if you have many events and some handle many triggers. Currently I have two less than ideal work arounds.


First work around is a text search. It gives a lot of irrelevant data for the results I want.  

Second I begin the process of adding a new "fake" event, and guess at what type of trigger the control is using (mouse down?, value change, etc.) If I guess right and it is being used I get a warning saying it is used and the event number (golden but often off by one because it counts the case I am pretending to add). Again if I guess the wrong type of trigger I get no help. 


It would be great if there were any events that were triggered by the given control, that would be added to the list of options under the right click find (and not show up if none existed like find local variables etc.)

I don't like wasted space. I see a good deal of wasted space in a cluster array when the labels are shown. What if we could size the clusters optimally and still see the labels by drawing them for the first clusters content. 



In my opinion, it's worth adding the option to pin the drop-down palette in the pop-up menu. It may look like this.

Now we have:


And after modofication will be:

Z nagłówkiem i pinezką.png

A Diagram Disable structure lets all the code that isn't inside of it execute but not what is inside of it. I think it would be helpful to put a structure around a snippet of code and execute only what is inside the structure. I usually copy and paste it into a new vi but it would be helpful to have that functionality within the vi i'm working on. 



With 6 or 8 input/output patterns it is extremely difficult to see difference between particular I/O. This is even more problematic you use for example INT32`s or other data types that have dark color as default.

One gets few pixels of dark blue with black border around it to make things even more difficult.




- Make an Assigning Terminals mode where the icon with terminals gets enlarged eg. x4 and where all terminals are clearly visible.

- Do not add more black borders, just stick to the data type color.

- Add clear indication which controls and indicators have already their terminals assigned (general information). User by clicking can see which one is assigned to what terminal (as it is now)





#1. So, I would like to see a zoom in/out tool on the LabVIEW BD panel. Its very hard while working large multiscreen codes and sometimes it's not possible for a wide monitor with high resolution.


#2. Another tool I want to recommend is to have a docking tool on VI/Type Def/Global Control FP so as to see the control and contents while in the background we can work on another VI.

Download All



The issue is that there are some situation where we have multiple developers using the same PC (Ex. limited number of test stations where HW/SW integration is performed).  The last developer on the station changes the Environment Options to their desired settings.  


To allow a developer to quickly switch to their preferred set of Environment Options, we would like a feature that would allow the following from the LabVIEW Splash Screen: (see image suggestion below)


  1. Save current Environmental Option settings and assign that set a name.
  2. Export/Import to from system using a file.
  3. List the Environment Option sets currently on the system in the Tools menu
  4. Recall Environment Option set by name


Tools Menu.jpg

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)

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



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.


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.

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.

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

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.