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

We currently need to use for loops to convert between arrays and sets:

Current Situation.png

This is not a bad thing in principle, but in my opinion there are multiple issues with it:

  1. These loops require a lot of space on the block diagram, which distracts from the *actual* code. The for loop provided on the palette in particular is absurdly large (and has a label attached to it). Most users probably won't use it more than once.
  2. The same code is used in many places to do the exact same job. This is a strong indicator for reusable code in the form of SubVIs.
  3. An empty for loop can confuse users who are new to sets.

I think LabVIEW should ship with malleable VIs to take care of conversions between 1D Arrays and Sets, because everyone who uses sets will need them eventually:

Suggested Solution.png

Download All

When working in LabVIEW in low light conditions, it would be nice to be able to have a quick way to switch to a dark mode, where the default block diagram colour would be a mid-dark-grey.

If I have an existing cluster in my project and one day I decide to delete one of the elements of that cluster, LabVIEW tries to fix all the references or black them out to help me find the errors.  However, It seems that LabVIEW in some instances keeps track of clusters internal controls with an index and when you delete something, those indexes are now messed up. 


For Example, if you have a property node linked directly to an item within that cluster, then you delete an item in that cluster, the property node now points to something else.  OOOPS! 


Also, if you have an Event Structure Case pointed to a control within this cluster, and one of the other controls in the cluster get's deleted, this Event structure case now points to the wrong thing!


LabVIEW is internally keeping track of the controls in a cluster with an index.  It works fine as long as you only add new stuff to the cluster.  But if you delete things, LabVIEW does not handle it well.

If LabVIEW instead had a notion of the name of the items, then it probably could recover well when an item was deleted from a cluster.

I like the "new" Review and Update Typedef feature.


What I don't like is handling the CASE structures I have connected to enums when the enums update. The constants for the enums update fine, but the selectors for the CASE structure are not included in this operation.  I really wish these could be handled as pseudo-constants for enums, allowing re-assignment of cases with a preview of old and new values.  I've started adding an enum constant to each case just to serve as a reminder which case it's actually supposed to be. And that feels kludgy.


Currently, case structures auto-adapt to enum indices. I'd like that to no longer be the case.

When using Quick Drop I like to place the QD window in a corner of the screen, where it remembers its location and will appear the next time I press ctrl+space. When working in a multi-monitor setup I'd still like the QD window to appear in the corner of the screen, but on the monitor which I'm currently using to edit a VI.


The idea is to display the QD window on the same monitor as the active VI window (front panel or block diagram), but in the same relative location on screen when it was last used. So if the QD window was on monitor 1 in the lower left, then I edit a VI on monitor 2 and open QD, it will appear on monitor 2 in the lower left (instead of on monitor 1).

Similar to how array and cluster constants on the block diagram can be edited, it would be useful to be able to edit map and set constants on the block diagram.


For example:


In the map constant above, the developer can scroll through and see all of the key value pairs in the map (plus an empty element at the end of the map).


It would be useful to also be able to edit the key-value pairs in the map (and add more key-value pairs to the map by changing the empty element at the end of the map).

Hi all,


When LabVIEW prompts the user to locate a file and the file is inside an llb or lvlibp, long names of VIs are truncated in the title bar such that the user cannot easily verify which VI was prompted for. This ought to be fixed by allowing users to resize the window horizontally.


Here is an example wherein it is ambiguous which VI is being prompted for. Allowing horizontal resizing of the window would offer a straightforward fix that would help people with waning short term memory capabilities.



The relevant LabVIEW help topic unambiguously refers to this window as "File Dialog Box".

I am not referring to the File Dialog function on the palette.


Thanks as usual!

Mr. Jim


A customer called in to NI technical support with the following idea pertaining to custom error codes and the Error Code Editor.


Is it possible to have Error Code Editor remain open during normal LabVIEW coding. This way customer's can add custom codes as they code their projects. The Error Code Editor found by going to tools->Advanced->Edit Error Codes... currently will not allow user to continue using LabVIEW until they have selected the close option as of LabVIEW 2019 sp1. This related to the fact that user must restart LabVIEW after editing custom error codes for them to correcty appear in a new error ring dropped on the block diagram.


If a error ring was already created, then the error code file (in XML format) has already been parsed. Thus no new ones will appear for use. If there was a way to more actively add and then use custom error codes, customers could make use of more error handling features.


Jesse Grigg

Technical Support Engineering

National Instruments


Just as for Clusters, I would like to be able to change a Map constant on the Block Diagram to be viewable as an Icon when it has been made a TypeDef.  You can't directly edit the constant data, so for me it doesn't make it worth the large amount of real estate that it can take up, especially if you have a Map of Maps/Sets.

So for example, instead of this:

I would like:


It would save me a lot of time browsing around the file system if, when selecting File/Open from the menu of a given VI, the file selection dialog that opens started at the same directory the VI is in.


Make that an option in LabVIEW initialization file, for people that rather have the current behavior.  Default to current behavior for minimal disturbance.


We have over 20 thousand files all over some deep hierarchy.  Sometimes we have two versions of that mapped in different places.  The time wasted navigating from one place to another is a bit of a pain.  Storing Quick Access directories only works up to a certain point.  it would also allow running two versions of LabVIEW simultaneously, without stomping over one another.


See this post in the forums where I asked for help with this last case.


When I connect something to the output of a Select node, I would like the input types to be updated to the connected output type.

For example, if I connect an enum to the output of my select node - if I "create constants" on the inputs, it should create the same enum type instead of a double. Similarly, when I connect a string to the output, I would expect the inputs to be strings as well.

If there is a conflict with the compiler, perhaps it could use whatever was connected first (input or output).

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.

This idea has come up repeatedly over the years: a new VI created in a library* should default to private scope. The point of private scope is to limit the number of callers of a subroutine so you can freely refactor the subroutine and know, without question, that the only callers that you can be affecting are the ones inside the library. This allows you to make API breaking changes freely because you can know you are updating all the callers. Note that if we did this, it would almost certainly have a Tools>>Options setting to change it, but the idea is to make "new VIs start in private scope" be the shipping default.


Each of the other scopes is more permissive in some way, with public being all the way open. For APIs intended for reuse and long-term stability, use of those other scopes ought to be a conscious decision.


The vast majority of VIs within most libraries should be private. There are some weird exceptions**, but most libraries have a few routines intended for the world to call and a bunch of subVIs that support the public ones. But going and setting the access scope to private is a lot of work, and many developers never think about it. For small shops, this isn't usually a big deal, but the larger the dev team, the greater the danger of highly interlocked libraries caused by someone reaching for some deep subroutine that just seems so useful, instead of doing the right thing and refactoring that VI out into its own shared library. 


I've seen some of our customers get really badly bitten by this, but it is an issue that takes years to build up, and then requires expensive refactoring projects to fix (or cloned code, which is sometimes worse in the long run).


C++ and C# default everything to private unless you declare public; I think that's true in most text languages.


But LV is a programming language for non-programmers, and not everyone needs to understand access scope, so creating new VIs as private by default would push yet another concept into the "you must learn this" category instead of "learn this when you hit a scale where it is useful" category.


In the end, I think access scope is a simple enough concept, one that most people using libraries get familiar with pretty quickly, and switching something to public is easy enough to do. Therefore, I think switching the default would do more good than harm. So that's what I'm proposing here.


* includes plain .lvlib libraries, XControls, LabVIEW classes, state charts, and any other type of library NI may introduce.

** such as the NI Analysis library, which is hundreds of VIs packaged together, mainly for licensing reasons, less because they have shared functionality.

While debugging LabVIEW, we often have many VI windows open. It can sometimes be difficult to manage these windows, especially once the debugging session is over. I think we can improve this situation greatly with a minor change to the All Windows dialog. This dialog (launched from the 'Window' pull-down or by pressing Ctrl-Shift-W) currently shows a list of all LabVIEW windows that are currently open:


There are several columns of information describing all the open windows, and the list is sortable by clicking a column header. You can multi-select in the list and click 'Close Window(s)' to close multiple windows at once.


Idea: If we add a "Time Opened" column that lists time stamps of when the windows were first opened, it would be easy to sort by that column, then close all the windows that were opened during a span of time, i.e. while debugging. 


While we're at it, there are several other usability enhancements that could be made to this dialog that seem to be low-hanging fruit:

  • Make the window a non-modal floater, with the list dynamically updating as windows open and close.
  • Add a 'Minimize Window(s)' button.
  • Give useful key navigation to the 'Close Window(s)' button (and any other buttons we may add).

I know there are other ideas about making debugging easier (don't show panels, etc.). I'm scoping this idea to improvements we can make specifically to the All Windows dialog to make debugging easier.

The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.



For community solution and examples of these features please go to ->


This could include also Pretty JSON since XML and JSON are interchangeable ->


Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.


(note: this idea is similar to this one, but different enough that I thought it warranted a new post)


LabVIEW 2019 will include a Clean Up Front Panel feature that repositions front panel objects to match their positions on the (already wired) connector pane. I think we should also consider implementing the opposite behavior, where you can arrange your front panel the way you want your connector pane, then assign that arrangement to the (currently empty) connector pane:


I envision the gesture used to employ this feature would be a Quick Drop Keyboard Shortcut, an entry in one of the drop-down menus, or a right-click on the Connector Pane.

We could add a way, for example a parameter key in INI file of LabVIEW.exe, in order to run LabVIEW.exe silently, so without the splash screen and the getting started window, like a background process.


Example use case:

When you execute a build specification thanks to LabVIEWCLI (operation name: ExecuteBuildSpec,, it runs LabVIEW.exe to complete the request. LabVIEW.exe is opened with the splashcreen and the main window. It's terrible, I want to use LabVIEWCLI to do some operation programmatically and silently (background mode) from my code/app.


It seems like every time I want to create a VI that has a connector pane which adheres to a particular type specifier, so I can pass a VI Reference into a subVI, I have to manually dig through the context help on that type specifier and find out what the desired connector pane is. Then after i create the VI and set up the connector pane, surely I will still get a broken wire on my reference, only to find out my connector pane connections are right, but my connection "requirements" don't match. I would love to have an option where you could right click a type specifier and "Create VI from type specifier" much like how we can create a callback VI from the register event callback node.

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.