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

Almost every widely-used software framework, ecosystem, IDE, ... has a public bug-tracking dashboard where bugs can be:

  • reported
  • monitored
  • voted
  • ...

Jira or Mantis are quite common solution.

As a NI user, the current situation it's really frustrating: even for bugs originally reported by me, the ticket is created by a NI engineer.

And so I don't know what information it contains, its priority, if someone is working on it, if it has been already solved, ...


Many years ago NI was a pioneer with the community, but now is ages behind everyone else.

Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.


Look at the picture: As programmer of the application "" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.




As reference: This is the content of Class 1




What I suggest and expect is the following:


=> The class tree shows all available methods within each single class!

bright colors: Methods that are defined in this class; pale colors: inherited methods



To make the class relation ship better visible I suggest to show the ancestor class name in brackets behind the name of the current class in the project view.

See the picture for better understanding:




When you right-click on a connector pane terminal, a context menu pops up -- but there isn't a good indication of which terminal you've clicked on:


You could assume that selected terminal is at the top-left corner of the context menu, but (due to a bug, I'm assuming), the actually selected terminal is a few pixels down and to the right of where you clicked.


What if the terminal you right-clicked on got highlighted while the context menu was shown?  This would provide visual feedback of the selected terminal, giving you confidence that you clicked on the terminal you thought you clicked on (and avoid mistakes of configuring the wrong terminal).  I can't even begin to count the number of times I've set the wrong terminal to "recommended" or disconnected a different terminal than expected. Could look something like this:


(which just piggy-backs on the appearance when you're wiring up a terminal:



Bonus points if the bug gets addressed where clicks are actually a few pixels off.

Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.


Proposal to make the Edit Items box longerProposal to make the Edit Items box longer


Windows 10 now handles long file paths although it has to be enabled with via various possible registry or group policy edits. Windows applications have to opt in. LabVIEW source code should be able to utilize long file paths.

There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:


NXG Style Path.png


Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.

Currently, the Panel method "Convert panel to screen coordinates" works fine normally, but if the panel is inside a subpanel then it just fails without throwing an error


The idea is to either update this function to work properly in a subpanel, update the documentation to mention it doesn't work within a subpanel, or throw an error to indicate failure.


A few similar ideas have popped up, for example:


but that one was more generic to get the a subpanel reference from within the subpanel.


(My specific use-case is to create a fancy menu popup relative to the clicked item within the subpanel- basically, I need screen coordinates of the "thing" inside the subpanel, which I cannot get without coupling the subpanel VI to the main VI by providing an upstream VI reference, which I don't want to do.)

Similar to Visible items>Radix right-click menu it would be highly beneficial to have the same possibility for showing (and switching) of Representation.




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.

There are two things that bother me about the index array. I think these changes would be useful to nearly all LabVIEW users.


  1. The default value is not optional (for integers always zero, a very useful value) There should be a way to set the desired value if the index is out of bounds.

    Image 1.png

  2. There should be a way to get rather the index is out of bounds from this primitive since this has to be check anyhow to know whether to use the default value.Image 2.png should look something like this: Image 3.png



The lack of these items usually proves to generate code that looks much uglier than necessary.

Although I do not know the internal workings of this primitive it would be hard for me to believe that this would have much of a performance impact. Also, bound checking arrays is necessary for many algorithms, why do it twice? 

On a For Loop that is configured to have parallel iterations there is a nifty feature when using errors on a shift register.  This feature is explained in an article here.  It basically ensures that For Loops that run 0 times, will preserve the incoming error as if the tunnel was a shift register.  However this feature also means that errors from iteration 0, won't be passed into iteration 1.  What is returned if the loop runs 0 times is just the incoming error.  But if it runs for more than that, the errors are all merged and returned will be the first error seen.



This idea is just to allow this already existing feature to work on non-parallel configured For Loops.  When would this be useful?  Say I want to delete an array of files.  I want to attempt to delete all files, even if there is an error in trying to delete some, just keep trying to delete the other files.  Initially you may think this:



But that has the clear problem that if the incoming array is empty, then the error will be cleared.  So we often do something like this.


And honestly this bit of code isn't that big of a deal, but this feature already exists.  However it only works on For Loops that are configured to run iterations in parallel.  In this case I might be attempting to delete files in a specific order due to their placement on disk, and running in parallel isn't what I want.


Since not everyone wants all errors in loops to act this way it would need to be a right click menu to turn the tunnel into a normal one, a shift registered one, or a preserve and merge one.


That is what I want.

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.




Currently, DETT looks like this:


But it should look like a proper profiler allowing for exploring and easily visualizing performance, threads, call stacks and memory usage at a glance (similar to this):





Check out this nice readable diagram:


Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.


I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either. 

Right-clicking on a VI in a project and selecting "Find -> Callers" doesn't list any .lvtest files which call the VI in question.  I think there should be a relatively easy way to find which unit tests call the VI.  I use Find -> Callers when I'm refactoring, and want to know what code might be impacted by a change.  It'd be nice to quickly find the unit tests which also call the VI.


Option 1) Have Find -> Callers include .lvtest files in the results alongside calling VIs.


Option 2) Add a separate Find -> Unit Tests


The function of "Compound Arithmetic" can be changed very quick and easy.

Why not use that concept for other items too?


Use cursor mode "Operate Value" to change function quickly.

Old: Click > Replace > Comparison Palette > Item

New: Click > Item


See concept screenshot for example:

Change Mode for all Items.png


The clicked item acts like an polymorph selector to choose from same palette or from similar items.


I have a 3D set of data, to which I fit a plane, and then from that plane fit a bounding box which should contain 99% of all data.

I would really like to plot both a scatter of the source data, and the surface within the same plot. Ideally the box would have transparency, but even lacking transparency it would be very convenient in visually confirming the quality of the fit. 

When I Control+Right click and drag to expand a block diagram. The expansion should NOT effect all of the unseen case frames


I am really tired of stuff like this happening when I expand the diagram of another frame of the same case horizontally and vertically.


This "Short cut" actually creates a lot more work for me as now I have to go back and clean up all the other states in my state machine that are messy now.




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.