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: 

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
0 Kudos

hello forum


what do you think about a "feature" where developers can enforce version control on applications deployed into end-user systems? it may sound something like some feature of a certain OS, but it may be beneficial in a way or two...


the most obvious being for version enforcement, some members may not like this, but often time newer versions of application are developed to address certain issues of the previous version, and it would be pointless if the end user kept sticking to the old version for certain feature they may have grown to like


it can also be extended to subscription based or trial version deployments, a more friendly way for developers to present their systems for customers for in-situ system trial


one way to deploy this feature, is to minimally trace the execution instances of the RTE in deployed systems, across newer and older version, log them for follow-up actions, that can range from friendly popup reminders for update to application execution prevention.


what do you think?

0 Kudos




0 Kudos

Using a ring control, it would be really nice if LabVIEW allowed the cases of a case structure to be defined by the ring contents, like an enum does rather than the ring value.  It would be easy to force it to have a default case to handle values that aren't defined by strings in the ring.  Just make sure you can still right click the case selector and tell it "add case for every value".  This would be very helpful when creating code to handle exceptions that return values in a ring and you want to handle each case.  It would be much quicker and less error prone than manually adding each numeric case that's defined in the ring.

For about a decade and a half I have consistently changed the default block diagram grid spacing to 4. Why, to match the shift arrow moves.  Hold it!  Why not make the shift arrow moves equal the grid spacing?  


Yes, I a genius!  The Kudos button is lower left!

0 Kudos

Is there a way to change the provided glyph size in the Icon editor? If not I think this should be added

I would like to be able to target an entire sub-palette for searching, rather than just a single vi.


That way, for example, if I want to find every vi that contains any of the Queue functions, I could get them all in a single search, rather than having to search for each vi in that palette.

0 Kudos

When testing circuits at different temperatures, one can simulate the

whole circuit at different temperatures, or using the Analysis and

Simulation PARAMETERS to target an individual component.


Both of these options are handy, but limited. What would be nice

if one could right mouse click on a component at set it at a fixed

temperature and see how the rest of the circuit behaves.


Thank you Application Developer if you decide to add this feature.  

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:

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

0 Kudos

The 2017 and 2018 versions of the LabVIEW OPC UA Toolkit support data access amongst other features.

Is there already a plan or schedule to implement the PubSub amendment (nr 14) and provide PubSub support for the OPC UA toolkit?

Make Trim remove non-breaking space characters.  This could be accomplished by adding "\A0" to the "regular expression" input.


Also, make "White Space?" return True for non-breaking space characters.


0 Kudos


0 Kudos

There are keyboard shortcuts with fairly universal adoption that LabVIEW does not utilize, but would be helpful. Two of these are:

  1. Shift + scroll wheel: for side scrolling in front panels or block diagrams. (And yes, this is useful in many situations that do not involve over-sized diagrams.)
  2. F2: for editing text content, i.e. of a selected label, comment, etc.

OK, using Malleble VIs is cool. Imaging being able to not only wrap code around a variable datatype but wrapping an object around a variable datatype.


I personally have quite a few classes which do pretty much exactly the same thing but which only differ by the precide datatype contained within its private cluster.  No changes in the number of elements, no changes in methods, only the datatype of the specific data.


Obviously, the datatype would have to be compatible with all methods and VIs of the class which use that data field or we would have broken code.

0 Kudos

When creating local variable , allow option for create as "read" or create as "write" .

Most times have to change created local variable to write after creation and it would speed up program development.

0 Kudos

So, in some inherited code there's lots of Compound Arithmetics where the input wires are either random or reversed from a neatness perspective.

It seems the Ctrl+click switcheroo only works on the 2 input version, and it'd be good if it worked on the larger ones. The way I see it work is either:

1. Hover over the input separator to switch those two specific inputs, which'd make a full reversal a sort of manual Bubblesort

2. Like the VI input selector, where you can select one and Ctrl+click another to switch those two.


(Atleast I cannot seem to do it in LV2017)



0 Kudos


I have written and read code that sets Disabled property many times, and it always looks the same.

Enabled or Disabled and Grayed Out.jpg




I wish I cold say the same thing with two nodes and one wire instead of five nodes and four wires. This is what I have in mind.

EZ Enabled.jpg




I am not attached to the name of the proposed property. I am partial to the Boolean data type and I prefer to go with positive language (enabled as opposed to disabled).


One alternative for naming is to use plain "Enabled" for the proposed property, and change the name of the old property to "Disabled Mode" or "Enabled Mode".





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.

There are already a couple ideas to retain wire values on a hierarchy (here and here). This is a request to disable (or toggle) the 'retain wire values' option on all VIs of a hierarchy in the same vein as 'disable breakpoints on hierarchy'. This request was spurred by an investigation into VI performance on resizing a very large 2D array of strings, wherein several memory allocation strategies and lookup strategies (arrays, maps, variants) had been exhausted, only to discover that a subVI whose (front panel and diagram had been closed) was set to retain wire values. Merely toggling the retain wire value setting off on this particular subVI improved performance by approximately one order of magnitude for this particular project.


Investigating and accurately measuring run-time LabVIEW performance can be challenging with so many debugging tools available, the impacts of which are not immediately obvious. For this reason, I would like to see a menu option that recurses on VI hierarchy and toggles the 'retain wire values' option, in the same vein as the option which removes all breakpoints from VI hierarchy. The option would be very helpful with run-time performance investigation or optimization.

0 Kudos

We like to keep the OS installation clean/stock.  That is, install RHEL and any packages required for the engineering applications and try to keep the installation packages to the minimum that are required.  Typically the EDA vendors will have a script that checks that all of the Linux package required the application.  If we find any dependencies we install on all machines.  The LabView Linux installation script wants to be run as root and install packages.  Would rather see a dependency check script so that we can install the dependencies ourselves and know what is being installed. 


For the application tool itself we don't want to install in /usr/local on all machines but rather install into a NFS mounted file server so that we only need to install once and not install on each machine individually.  The current Linux installation script doesn't take an argument to specify an installation directory other than /usr/local.