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

I would love to see the ability to add additional fields to the Project explorer. 

Execution settings would be of particular interest.  

"To Index or Not To Index"  

For While Loops and For Loops, the Auto index tunnel should be turned on or off based what the end of the wire is connected to.


For array wires coming into a For or While loops if I connect it to a scalar input then Auto Indexing is ON. If I connect it to an array input then Auto Indexing is OFF.


For scalar wires going out of a For or While loop if I connect it to scalar input then Auto Indexing is OFF. If I connect it to an array input then Auto Indexing is ON.  





Wires going into polymorphic input will default to normal mode, Index for For Loops and not indexed for While loops.

Loops that generate arrays with each iteration sometimes need to be appended or concatenated together and retain the same number of dimensions when brought out from the loop.  Currently this can be done using a shift register along with Build Array, Insert into Array or Replace Array Subset for example .  Such wiring could be eliminated and diagram space saved if the generated arrays could simply be wired to the loop output border and an option to Auto-Append or Auto-Concatenate provided.  This would be similar to the existing Enable Indexing option except that the array dimensionality would remain the same.  This would be useful for example in while loops that are extracting currently available data from an acquisition process where one wants to build up one array containing all the final data.

It would be nice if under options that highlight execution speed for debugging was configurable.  It could also be not an option but placed just next to the light bulb icon.  With experience we become able to folloe the code much faster and having 2 or 3 speeds of highlight execution could save some waiting time.  I know that there are many debugging options already but sometines the old light bulb is easiest.


The context help that appears when you hover the wiring tool over the various inputs and outputs of a subvi or function should display the data type required by the vi/function.

That way we would not need to guess the datatype to get rid of the coersion dots.  Currently I end of making a constant from the terminal and then hovering over that to see what data type it is.  Since the IDE knows the data type to create the constant, there is no reason it cannot be appended to the help description.


Why different path's are not enough ? 

So that the developer can work on the different version of the program,

and not to bother of getting a "mess" of vi's and controls.

It would be nice to have bookmarks (possibly based within the project) so that you could quickly jump to certain areas of your code that has to be modified or reviewed frequently.  Obviously, things like state machines are self documenting, but it would still be great if you could quick jump to certain areas.  Being project based, you could also jump to any bookmark in a subvi.



If you want to fork a VI (start a parallel running VI), you have to load the VI reference, use the set control elements values method to initialize the controls of the VI, and than start it with the run VI method without waiting to finish. Quite complicate, if you ask me.


It would be cool, if there would be a fork VI method, which you call inside the VI you want to fork. The method copies the VI to a new place in memory including its actual running state. The new copy just goes on as it would without the fork, while the calling VI would get back the values of the ouputs, which they have at the moment of the execution of the fork method. Of course this does only work with reentrant VIs.


I can think of a LOT of applications which can use this!




Allow probes to be added to unwired signals, E.g. interation number in FOR/While Loops, unwired subvi outputs, etc....

In the latest years the monitors and the graphics card became more and more advanced supporting very high pixel resolution.

Using a 1600x1200 is common now but this could create problem whit labview due to the absence of a zoom function.

The VI connector at that resolution are too little and near so could be difficult to work with and more in general all the block diagram of a VI could be diffucult to edit.

So i suggest to implement a zoom in\out (maybe using the mause wheel) function also in labview like in a common CAD sw

Hello everybody,


here are my ideas about expanding the functionality of Event structures:


1.) Make it possibly to dynamically register references like tcp/ip, visa, queues, etc. for Event structures. Possible events are "new bytes at tcp/ip", "new bytes at seriel port", or "connection closed". In the case of queues it could be the same function as "Dequeue Element" or "Queue referenced closed". There are certainly a lot more of similar references, which could be registered for catching events, which up to now we have to poll regularly or use other event functions (as in the case of visa -> new bytes at seriel port). Benefits are: no more regular polling of changes, better integration of several functions (like using queues to communicate with GUIs instead of dynamic user events), and in my opinion just better code.


2.) Allow for better handling of the event buffer for fired events of Event structures. I would like to have a feature to list and remove item(s) from the buffer of fired events. Otherwise you have always to write some code to catch events, you d'ont want just to execute or you want to remove, because you just pressed the stop button. This could be realised by new leftside and rightside nodes inside the event structure.


3.) It should be possible to configure events to run first (placing the fired event as the next event to execute like the queue function "Enqueue Element At Opposite End"). Or add priority to events.


4.) Make it possible to add conditions to events, e.g. only allow event foo, if condition bar is True. I'm not sure, how this should look like. Some static conditions could be "key pressed == a" coupled with "key down" event. Conditions could also be coupled to controls via registering the control reference like dynamic events. If my 1st idea is realized, a condition could also be something like "tcp/ip connection is online". If a condition is not fullfilled, than either nothing happens or there is a leftside node, which indicates the status of the condition. This should be configurable.




Be able to open the block diagram with a hot key or right click menu even when you use custom menu on user interface. This option should be available for debugging in development environment and when debugging an executable with debugging enabled.