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 Kudoed 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 faced to delete multiple elements form the array which is having 20 steps.



if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.



Array element.png



I´d appreciate an event that is called whenever there is a change of Top cell (row). Several times I needed to "align" visible content of two objects (listboxes, trees, etc.). Value change or mouse scroll event can be used but still I´ve found no way how to catch when the user uses scrollbar arrows or draging scrollbar position indicator. The only solution I found is to keep it aligned by periodically reading out Top row visible property of one object and set it for another one. That requires code in Timeout event that is called very often (otherwise it is noticeable for user) causing performance drop.



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.




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.

Instead of doing all this:


I would like to be able to just drop a VI on the Start Asynchronous Call node, and get this:


The "Probe Display" pane of most default probes should have indicators that are set to "Fit to Pane". The worst offenders, in my opinion, are Strings and Variants...I often find myself cursing the fact that I can't see more of the data, and usually have to copy & paste into Notepad++ or something to actually see what I'm looking for.


Yes, you can make custom probes for this behavior. But it should be native.




Maybe this has been already requested elsewhere and I'm missing it....

but it would be useful to have a Wait (ms) with connectors for error in and out.

This can help keeping the BD clean...



I am struggling with my Event Structure event list and the corresponding list of cases in the parallel consumer loop Case Structure.

Both have currently over 100 cases each and finding one or scrolling down to access the latest one has become painful due to the lack of a scrollbar in these lists.

For instance, here is the Event Structure list:


Screen Shot 2015-09-29 at 12.19.16.png


Same goes for the list of controls in a Local Variable (and other objects, I am sure).

There is no reason why such lists do not have a vertical scrollbar when that corresponding to a Enum do have a scrollbar:


Screen Shot 2015-09-29 at 13.33.30.png


Or is there?


Suggestion: All long pulldown lists should have a vertical scrollbar


When using Typedef's I often have teh control wire passing through a VI. If I need to modify the typedef, I have to either create an instance of the controil/indicator, or got to a VI that uses the typedef control and the righ-click. From here I can open the Typedef.


What I would like to do is to be able to right-click on the wire and select directly 'Open Typedef' without having to go to a control.


It is a minor issue, but if I am in the middle of development in a VI, I don't want to have to click away from the VI under development to find the control. Additionally, creating a constant so that I can right-click on it is also not so convenient. If the Typedef is a large cluster, the block diagram may be distorted when the Typedef appears.

I have often the case, that i have to display an array of cluster. It takes a lot of space on the front panel to show all the captions of the cluster elements, cause they will be shown on each array element. A better solution would be, showing the captions or labels just on the top visible element.



(Inspired by this discussion)


The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).


The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.


According to some engineers that I have spoken to in the prototyping industry, Windows 10 IoT is gaining some traction as a preferred embedded OS for developing ideas.  Windows 10 IoT, as I understand it, is delivered in 3 different versions: Core, Enterprise, and Enterprise Mobile.  Now where Core is built as a .NET application and lacks some of the system capabilities of Windows 10, the Enterprise version is built as a Win32 OS and is closest to Windows 10 as it is now.


If resources allow, it might be beneficial to see some future support for at least this version of Windows 10 IoT to meet the demands of a growing body of engineers who will want to integrate LabVIEW executables with their Windows 10 IoT powered devices.

Languages like 'R', 'Python', and MatLab (yes I use the old name) have these.  They are useful.


One of the key ideas in LabVIEW is that the user needs minimal interventions to code a useful result.  As more information is encoded in a data type there is more opportunity to make "hands free" code that "just works".  I think these two data types can do that.


Data Frame:

  • Primary data type in R
  • It is Array-like, but NOT an array
    • each column contains one measurement (row) on one variable
    • It acts like a list of vectors, but the vectors have the same number of rows, and indexing allows a return of all or subset from all columns
    • column types are heterogenous - they can be different
    • column types can be set.  A column of 0 vs. 1 can be set as factors/binomial values or as continuous.

There are functions that data analysis folks do every day that are informed by variable type, so the function operating on the inputs doesn't need type specified because it is interior to the table.  This means you can say "plot(mydata)" and if your data is set up well, the graph parameters are already specified and useful.


Some references:


Data table:

This is from Hadley Wickham, a very famous person in 'R'.  He does great work, and his name has high brand value in data-analysis.



  • Uses the "data.table" package
  • is able to be screaming-fast (think roller-coaster) especially when used with the "split-apply-combine" approach to data analysis, and SQL-like operations.
  • is built for handling huge data (100GB tables) quickly and efficiently.

In many applications the same operation is not possible due to memory constraint or viable due to processor overhead can execute adequately (aka wonderfully) by using this data type on the same hardware.







While there are ways to temporaily disable autowiring, some should never happen in the first place. For example if the resulting wire has a net right-to-left flow, it should not be created at all!


Let's have a look at the following simple scenario (see picture):


Place an "add" primitive (or almost anything else!), then use ctrl-drag to create a second copy right below it. (Sometimes we need to add a few different things in parallel!). LabVIEW immediately connects a random input and output with a circuitous backwards wire for no good reason at all. Smiley Sad



If I really wanted them to be connected, I definitely would have placed them side-by-side!!!


Idea summary: if any auto-generated wire would result in a net backwards dataflow, it should not be created at all!

Here's how we currently make cluster element labels appear, and a proposed idea for improvement.


This idea is an extension / alternative for this idea:

You can give Kudos to both ;-)


Sometimes it's very useful to modify a front-panel decoration element programatically. E.g. moving it, changing its size, color or visability. All of those properties do already exist but it's hard to reach them (if your read the other idea, you'll see that it is even imposible for a specific element).

What I'd like to have is a right-click-menu-entry "create property node" (same for method node). The result shall be a property node appearing in the block diagram which is linked directly to the decoration element.



(This is different and less controversional than  this related old idea)


Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.


As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.


If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).


Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.




IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.




My idea is to have LabVIEW cease and desist it's self-important modal behavior.  Not that I think LabVIEW is anything other than the most important application I run, but I don't think it should force its (many windows') way to the front of the line when I shift focus to a LabVIEW window.  I didn't find any other idea that matched this, but there is this discussion that covers the notion well.


An example case:  When chasing efficiency I frequently have Task Manager open to observe CPU usage when I change front panel controls.  I'll run the .vi and load Task Manager, but when I click on a front panel control ALL the LabVIEW windows come to the front and cover Task Manager:Modal.png


So, my suggestion is to have only the selected LabVIEW window come to the front.  I get the impression that Ctrl-Tab and Ctrl-e behavior are why LabVIEW controls its own window z-placement, but leaving their function out of it, my suggestion is just to change the modal behavior of LabVIEW windows.

NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.


I suggest that NI start shipping USB keys instead. USB has several advantages:


  • USBs are smaller
  • USBs are more usable on devices without DVD player
  • Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
  • USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.


Ship developer suite on NI USB keys