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: 
Post an idea

NI's response to the ideas thus far appears far too sporadic. For example if you check out the top LabVIEW ideas ( 7 of the top 10 ideas are still listed as new! Adding insult to injury the average age of these ideas to date is 1,017 days! It is ok to decline ideas but please provide us some indication that this is something you take seriously. It would appear that NI is cherry picking the easiest half dozen or so items from the list so you have a marketing gimmick to list on the LabVIEW release notes. I propose that a threshold is set and made public so that if an idea reaches a certain amount of kudos, R&D must address it, even if that means declining it.

When programming with large applications, often times you'll have clusters carrying a lot of information.  If you hover over the cluster wire and observe Context Help, you might see something like this:



This Context Help window above is rather large and doesn't necessarily make it any easier to see the structure or contents of the cluster. My proposed idea calls for the ability to expand or collapse the cluster contents within the Context Help window, such as this:



What do you think?


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:




I'm telling my strudents how they should use the error cluster and how important it is. In subvis no error dialogs should be shown and so on (see topics of LabVIEW Core 1 / Core 2).


But many VIs written by NI have been programmed very sloppy.


Example: VI "Write into spreadsheet file". The error cluster is not wired to the inputs/outputs and if an error occures, an error dialog would pop up. Here is the block diagram of your V "Write into spreadsheet file"I:




Please check all of your VIs and do a revision that we can make well-coded applications where the error handling will work correctly.



Probes are so useful for debugging, but monitoring them within the Probe Watch window can be a headache. I constantly find myself focusing back and fourth between Probe Watch and the code to translate a probe number to a position in the code. A solution would be to have the probe's value float just above the probe itself. LabVIEW already has a similar feature. When you use Highligh Execution wire paths display their current vaules, but using Highlight Execution is too slow and no practical for every debug situation.


Here is the issue as it stands today:



Here is my proposed new feature! :



Element of Set? returns whether a single element is a member of a set. In order to check multiple elements, we currently have to place multiple nodes on the block diagram, which is rather redundant:


Current Situation.png


I would like to be able to connect multiple elements to a single node and check all elements at once:


Desired Behavior.png


As an example, I need to check if either of two elements is part of a set. If one of them is, add the other, otherwise do nothing:



This is certainly not a deal breaker, but in my opinion it makes sense to allow multiple elements to be connected to this node, especially considering that it is read-only.

A graphical programming language deserves to have great graphical tools representing the design of big applications.


It is possible to use scripting to understand if a method of a class has another class as input or output terminal and to know if a class composes another class in private data. The only thing I cannot do right now myself is to show this information in Class Hierarchy window. Representing the usage and composition relationships only requires parsing through the project once, and then every time it changes. 

I am right now using a script to parse through all project classes to understand which have what relationships, which are actors and which are messages and I draw a Plant UML diagram from that. The intermediate step is to generate Plant UML text, but this should be integrated into LV.





Please improve the readability of object oriented project with additional tools for LabVIEW. This is especially critical for NXG, where the currently the ability to understand an OO project is even more limited than LV19.

In Enthought's python integration toolkit (PITL), the "Open python session" VI accepted as an input the path to the python.exe file to use for the python kernel. In LV2019  the "Open python session" accepts a string "2.7" or "3.6", and then labview searches the system path to find the python installation.  The LV2019 method is vastly inferior to the PITL method. Due to the way the LV python node requires one to manipulate the system path in order to find the desired python installation, I realized that this is a complete non-starter for sending compiled applications to end users, because the end user may have multiple python installations on their computer, and I can’t expect them to bend over backwards just to be able to use my compiled LV app.


I do not know how NXG currently handles this, but I hope that they emulate the PITL method. Furthermore, it would be great if NXG could handle arbitrary python distribution, such as Anaconda, rather than just the bare bones installation from It would also be great if there was more documentation about the python node in general--there is very little to be found currently. The Labview python node is shrouded in mystery (e.g. what the heck is NIPythonInterface.exe) whereas the PITL was very self-explanatory. It is a shame that NI displaced such a useful product and replaced it with an inferior one.

Picture says it all.


Concatenate with an option of 'concatenate to new line'



I am not allergic to Kudos, in fact I love Kudos.


 Make your LabVIEW experience more CONVENIENT.

In 2014 the Clear errors VI now accepts a single error which can be cleared.  This is nice but when I heard NI was implementing their own filter errors, I assumed they would do it in a similar way to the OpenG Filter Errors VI, which accepts a scalar, or an array of error codes to filter.


In addition to this I think it would be helpful if this Clear Errors also accepts the error data type for errors to filter, or an array of errors to filter.  That way the Error Ring can be used to help readability of the block diagram showing the error that is being cleared.


Improve Clear Errors Filter.png

After placing a new graph, we might want to go to the plot properties dialog and change the color, label, etc. of the plots we want.

Bzzzt. No go! We can only edit plots that have been added in some other way. (by resizing the plot legend, wiring and running once with data representing several plots, etc.)


For comparison, have a look at the cursor tab. Here we can add and remove cursors at will.


My suggestion is to add the ability to add or remove plots on the plots tab properties page of graphs and charts.

It could look like in the image on the left.




I really hate having to dig through a long hierarchy of menus when I know what I want:









Visual Studio (and other MS and non-MS products) have a feature called Intellisense, which is meant to make this easier. Basically, as you type, it pops up a list of matching objects, based on context, so you can quickly select what you want:








It would be nice if LV had a similar feature - click on a property in the property node using the text tool (or Ctrl+click if using the auto-tool) and now you can type in the property name and you will get an Intellisense-like pop-up, which will have all the relevant properties.


Specific features it could have:


  1. It should know all the relevant names - full names with the hierarchy (Boolean Text.Font.Color), long names (Mechanical Action) and short names (MechAction). This could probably be similar to how Quick Drop handles shortcuts or they could simply appear as separate items.
  2. It should be context sensitive. If the class is Boolean, then there's no need to have Listbox properties in the list.
  3. It should match all the properties which include the search string (so "in" on a boolean would match both "Indicator" and "Strings[]") and only them.
  4. It should have the ability to use caps for acronyms (e.g. in the above screenshot you could use "BT" instead of "Boolean Text", similar to what appears in this video).
  5. It could probably also work on the invoke node, although there it's less needed.
  6. It could probably also be used to quickly select a class if you have a class specifier using the same basic mechanism.

This example (LV 2009) shows how useful this could be. You don't need anything installed. Just run the VI and start changing properties.



  1. It will only work on the last property in the node.
  2. It doesn't have the proper list of names and it doesn't implement all the features in the idea, as this is just a basic example.


Note - this is similar to this idea, but I think that it's much more usable. Also note that the second idea refers to a QDKS which ships with 2010, but that is far from perfect.

I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 


The list of available LabVIEW modules and device drivers is very long. Their names tend to be long too, which is compounded by the many levels of nesting. Modern screens are large.


Given all that, why are we selecting software components by scrolling around a tiny window which can't be expanded?



(Note: most of the trees above aren't exen opened yet!)



Proposal: Make the window bigger (vertically and horizontally), or resizeable, or both.


Thanks for listening!

With the advent of the IoT and the growing need to synchronize automation applications  and other TSN (Time Sensitive Networking) use cases UTC (Coordinated Universal Time) is becoming more and more problematic.  Currently, there are 37 seconds not accounted for in the TimeStamp Which is stored in UTC.  The current I64 portion of the timestamp datatype that holds number of seconds elapsed since 0:00:00 Dec 31, 1900 GMT is simply ignoring Leap Seconds.  This is consistent with most modern programming languages and is not a flaw of LabVIEW per se but isn't quite good enough for where the future is heading   In fact, there is a joint IERS/IEEE working group on TSN 


Enter TAI or International Atomic Time: TAI has the advantage of being contiguous and is based on the SI second making it ideal for IA applications.  Unfortunately, a LabVIEW Timestamp cannot be formated in TAI.   Entering a time of 23:59:60 31 Dec 2016, a real second that did ocurr, is not allowed.  Currently IERS Bulletin C is published to Give the current UTC-TAI offset but, required extensive code to implement the lookup and well, the text.text just won't display properly in a %<>T or %^<>T (local abs time container and UTC Abs time container)  We need a %#<>T TAI time container format specifier. (Or soon will!)

I've already made a post on extending File I/O operations so I figured why not make a post on my most commonly used OpenG palette, the array palette.


There are so many good nuggets of Array manipulation code in OpenG.  This stuff isn't perfect, and could be optimized, but the convenience of it makes sense especially when you realize there is so many things you can do with arrays.  Lets start with the Index Array, one of the most commonly used functions.




Here we see the native function allows for an N dimensional array to be indexed.  The OpenG function only supports 1D and 2D arrays.  And when using a 2D array, the OpenG function must specify both a row and a column, you can't index an entire column or row.  Both of those are very useful features of the native index, but there is something the OpenG function does, that the native doesn't, and that is index multiple indices.  You can pass in an array of indices and pull them all out in the order defined.  This can be used as a reorder function that takes an array and scrambles it the way you like.  Adding this feature is already on the idea exchange.




Again when it comes to polymorphism the native function beats OpenG.  The native delete supports deleting from N dimensions where OpenG is just 1D or 2D.  But OpenG allows for deleting multiple indices from an array, and if it is a 2D array you can specify if you want to delete rows or columns.  This would be a nice addition to the native function.


cond index.png


A conditional auto index function doesn't exist natively in LabVIEW.  You can perform a similar function with the conditional auto index tunnel on a for loop but having a single function would be useful.  This idea is on the exchange in multiple places, Link 1, Link 2.


Remove filter.png

Ever need to remove duplicates from an array?  Or remove all zeros or NaNs from an array?  These two functions do just that and on the forums all the time are requests for functions like this with no direct replacement on the native palette.  A nice feature of the remove and filter are they output the indices that were removed.  Combined with the fact that the delete, and index accept multiple indices make these very useful.  Also the items to filter for the filter can be a scalar or array which is nice.



Ever want to sort an array and know how it was sorted?  This OpenG function can do that along with specifying what order, ascending or descending to use.  The OpenG sort also supports 2D arrays where you can specify if you want to sort on rows, or on columns.

I'd love to see an option for the label of structures to be visible by default, similar to the already existing "Subdiagram labels visible by default" option.


structure labels visible by default.png

Cluster Size as a Wired Input:


  • Easier to see
  • More implicit
  • Nearly impossible to forget to set it (if it were a required input).

 Cluster Size.gif

The current implementation of Control References on the Block Diagram could be improved. This Idea was first conceived over a year ago in a discussion on Smaller Static Refs, in the comments here.



Consider the following advantages:


  1. It's generally bad style to have Ctl Refs with hidden labels. New implementation always demonstrates the label to comply with inherent self-documentation of G (just like a Local)
  2. Smaller footprint combined with better visual distinction between Ctl Refs doubly improves information density
  3. In general, the Control Class does not need to be shown at all times on the BD. Rather, it could be shown in Context Help (currently, CH is not useful when hovering over Controls Refs, but this is another topic), or determined by browsing Properties/Methods.
  4. Eliminates the undesirable ability to rename/delete a Control Ref Label such that it no longer matches the Terminal Label.
  5. Creates a better distinction between a Control Ref and a Control Class Constant (NULL Ref). The color of the Static Refs denote a "live link" with a control, while the muted tones of a Class Constant indicate no such link (NULL)
  6. Complements the new LV2010 Local Variable upgrade (see image), yet remains distinct by having a different glyph, different background colors, and no directionality arrow
In summary, a Control Reference revamp could reduce the footprint, increase readability, and prevent obfuscation that decouples the Static Control Ref from the Control.

So the request here is to have an option wherein the array indicators (or controls) can be linked with another array indicator (or control) and can be scrolled synchronously.


There could be a property node for that (or invoke node or may be some other way), which will accept the reference of another array and thats all.


Sync Scroll

In above example, Array 1 is linked with Array 2, so whenever the user will scroll (or change the index of Array 2, the same change will reflect in Array 1.