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

I find myself writing this type of code more and more recently.


ci current 2019-08-13_13-53-21.png


It would be nice to have an easier way of achieving this (for instance either of these below could work):


ci new v2 2019-08-13_13-53-33.png ci new 2019-08-13_13-53-33.png


Showing the false terminal could be done with the right click menu


ci new menu 2019-08-13_14-15-43.png





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.

I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire.  I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal.  I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:


1.  Wire this specific VIM on error wires most often

2.  Likely don't want the VI to stall in the event of an error

3.  Would prefer to see that error propagated as quickly as possible like most other VIs do



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:


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

(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)


I've got some code on my diagram:


I need to wrap the code in a case structure, so I do:


Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.


There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:


If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:


(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)


If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.


With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.

It would be nice if the LabVIEW primitives for TCP allowed for the creation of a socket without actually connecting it to an endpoint.  My thoughts are that there would be two new commands added to the TCP palette:


TCP Create Connection (Advanced)

TCP Open Connection (Advanced)


TCP Create Connection (Advanced) would create the socket but not perform the connect() method on that socket.  I would imagine that it would otherwise look and feel quite like the current TCP Open Connection, except that the user would need to manually run TCP Open Connection (Advanced) afterwards that would perform the connect() method on that socket.


I have a need to access the raw socket object before it is connected, using the TCP Get Raw Net in the vi.lib\Utility\tcp.llb library.  This VI works to get the handle that can be used by winsock and other Windows DLLs, however, it only allows for setting properties for a socket that is already connected.


Specifically I have a need to enable Windows FastPath for TCP to optimize the rate at which I can stream data between two applications.  Per the specification, this option must be enabled BEFORE the socket is connected.  Right now I can set this for the listener on the server side (TCP Create Listener creates a socket but does not connect), but I cannot set it for the TCP connection on the client side as the first method it calls is TCP Open Connection which returns a socket that is already connected.

One improvement that I can see helping both idea suggesters and moderators: Help us know the scope of potential LabVIEW change.


Many ideas here are marked complete because they've been implemented in NXG. (Samples 1, 2, 3)

The message I get from this status is, "That's a great idea. We'll put resources toward making our next-generation product do that awesome thing, but it's more work that we want to do on the current generation product."


Many others are marked declined because significant changes to LabVIEW aren't planned (presumably in consideration of end-of-life). (Samples 1, 2, 3)

The message I get from this status is, "That's a great idea, but it would cost us more than we want to put into our current-generation product."


I think both of those messages are totally valid, but I find myself increasingly reserved about suggesting ideas here because I don't know where those thresholds lie. Could the community receive some guidelines on what type of change might make it into LabVIEW? If we had those guidelines, we could save our own time by only suggesting things that might make it in and we could save the moderator's time by reducing the number of ideas to have to process.

The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.


I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.

When a user clicks and drags a slider - hundreds of value change events are generated for your code to handle.


Most of the time the user experience you want is just to use the value when the user has stopped dragging the slider. Similar to a text input field where you can select to have the value update only once the user has finished typing instead of all the intermediate values.


My proposal is to change the slider events to support this use case. I'm inclined to leave the exact solution open - as long as NI can support this use case.


There is another idea to add an ended event which would allow for this: but I created this post to be more specific.


You can find a number of attempts if you search the forums for "slider too many update events" such as 

If you follow this through there are always compromises in every solution for getting this behaviour.

Simple idea is to make the icons found in the palettes, the block diagram and help all match.



The icons in the columns are all the same function, however, there are some significant differences. It is reasonable to expect the help menu icons are expanded to show additional functionality, but there is no reason why the palette and BD icons should be different. The core of the icon in the help menus should be the same too.

These icons screen shots are from LabVIEW 2018.

Here's an enum with a lot of elements:


The enum has a built-in right-click menu to 'Select Item', but it's worthless... it does exactly the same thing as clicking on the enum directly:

I think we should replace the 'Select Item' right-click on enums and rings with a Quick Drop-like UI that lets you filter the enum/ring contents and select an item without having to scroll a giant list:

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.

Using the application builder is problematic if the destination folder is monitored by syncing tools such as Google Drive (Backup&Sync), Onedrive, etc.


During building, there are tons of file operations in rapid sequence, potentially crashing the sync tools or causing false file conflicts (recent example).


To avoid these issues, I wonder if the building steps could be forced to take place in the temporary folder, followed by a final clean move to the destination. My guess this would make building more stable and compatible with external folder syncing tools.


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

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.

The Preferred Execution System setting of a VI allows for more explicit developer control of a VI's thread allocation. Currently there is no way to quickly view which VIs have been configured for which execution system. Furthermore it's not easy to see what execution system a VI configured with 'same as caller' will run under.



This idea is to add an optional color coded representation of each execution system to the VI Hierarchy window. When enabled, each of the execution systems is highlighted with a certain color around VIs, and applied to the lines between VIs.




For VIs with an explicitly configured execution system, the color around the VI would be solid. For VIs set to 'same as caller', the color around the VI would match that of parent in the call chain, but have a different appearance (shaded diagonal colored lines in this example). For VIs which are 'same as caller', but called from multiple different execution systems, the color around the VI would be shaded black.


Full resolution example:


Adding this option would allow the developer to quickly view what execution systems have been configured, which ones are not is use, and potential call chains of each execution system.

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



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.