NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea
Charts assume that the X-values always represent evenly spaced points. With LabVIEW 's charts, you only provide the Y value, and do not specify the X value.
For arbitrary X-values, one has to construct something (usually involving shift-registers).

Often charts are meant to display values as a function of time. If one changes the acquisition rate, one would expect the chart to change accordingly.
As LabVIEW only allows you to scale (and offset) the chart's X-axis, it would be nice to have a timestamp input (for instance expandable form the chart's terminal).
Resulting chart would look like this (here two plots). 
Chart with time stamp.png

Abort Asynchronous Called VIs when the parent stops

Status: New
by Member JimZ1 on ‎10-10-2011 03:42 PM

Currently when a vi is called asynchronously, it will live - even when the calling VI stops.  This may cause problems in some cases - for example, code that uses the "first call" function.  During development, it is not unusual to have a VI stop inadvertantly without proper cleanup.  With Asynchronous VIs running in the background, you must shutdown and restart your project to clear out these Asynch VIs.  It would be nice to have an option on the OpenVI function that caused the Asynch VIs to abort in the event that the calling VI shuts down inadvertantly.


Probes with Radix visible

Status: New
by Active Participant Guruthilak on ‎12-23-2009 02:43 AM

1) I would like to see the "radix" visible in the probes for "Numeric probes" and "hexadecimal/coded display" for "string" probes



2) A shortcut to make the selected "control label" in the front panel or block diagram to make it BOLD. (CTRL+SHIFT+B) or anything equivalent

So I was looking at the idea submitted "Remove Common Error Functional​ity From Set/Unset Busy Cursor" and I came up with a more useful, and more generic way of dealing with that problem, and the problem of 'anchoring' code for flow-of-control in general.


I too use flat sequence structures to force flow-of-control, and there should be a better way. There is.


Suppose we simply add 'ignore error' functionality to the error-in/error-out terminals? In that manner you could create a vi just the way that you do now, with error in/out, but by right-clicking on error-in and selecting 'ignore error' the following would happen:


1. The VI would ignore a pre-existing error. It would run as if no error was present on error-in.

2. The error-in terminal would change color (or shape, or size, or relgion) so that it was visually obvious that the 'ignore error' functionality was enabled.

3. The error code passed to the VI, although ignored within the VI, would still be passed thru to error-out.

4. If the VI that was called with 'ignore error' generated an error, that error would still be added to the error codes output.


This hasTWO major benefits: (1) it provides a super simple way to create VI's that need to execute in order but don't need/want error functionality, without requiring the user to add unnecessary objects (like flat sequences) or write special code to use it; and (2) it allows you to write routines that should run regardless of whether an error is present or not, but still allows them to post an (additional) error if they need to.


Hide Non-Class-Specific Property Node Selection Menu Options

Status: New
by Member KeithTK ‎08-12-2013 03:23 PM - edited ‎08-12-2013 03:51 PM

If I've just wasted time digging through the ridiculous class selection menu, why do I have to waste more going over all the less specific properties?

It is particularly painful when having to scroll to items off-screen, and do it multiple times for nested options.


LV Idea Exchange Property Node Menu.png


Hide the higher level stuff!  Put it in a menu with a better name than I could come up with or at least hide it with an expandable arrow.


These menus need way more improvement than this, but for a step-1 this is easy to implement, I hope. 

I would like a better way to clear the list of recent files and recent projects in LabView.  It is often disireable to clear the history when changing to a different project or a different user.   Currently the user must close LV, edit the .ini file and restart LV.  I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.


Updatable system controls / indicators ...

Status: Declined
by Active Participant manu.NET on ‎11-23-2012 07:01 AM



The mechanism of "system controls or indicators" is very good because you can build User interfaces with an OS like look !


The problem is that many properties of these controls and indicators are no more updatable.


It would be nice if some properties could be changed ... like the colors properties ....

This could be helpfull when you want to highlight an error or a warning ...


How many times i made the same error ... modifying the backgound color of a system control !

And then i had to replace my controls and indicators by classic,modern or silver one ... my HMI get then a very bad look !

The minimum to do would be to hide the unupdatable properties from the properties lists.


Thanks for your help.

Status: Declined

Version independent source code saves

Status: New
by Active Participant ErnieH on ‎10-18-2010 08:54 AM

Give the user the ability to save the LabVIEW source files as un-completed, version independent files capable of being imported to any version of LabVIEW. Of course, newer features won't be recognized, but the vast majority of the code should be useable.


Run-Time Menu Editor Improvements

Status: New
by Active Participant Mr._Jim on ‎04-04-2011 09:54 AM

Hello all,


I'd like to suggest some improvements to the run-time menu editor dialog:  (This is found under Edit->Run-Time Menu...)


1.     Allow the window to be resizable.  (Scroll bars are no fun)


2.     When using source control (Perforce in my case), prompt the user to check out the .rtm file upon the first edit. (Same behavior as when editing VIs)  At present, if I forget to check out the menu file I get a very ugly dialog followed by an "Emergency Backup Destination" prompt.  [insert muttering of naughty words]




I'm then faced with two choices: Either I can save an "emergency backup," as the prompt refers to it, or lose all of my changes and edit my menu all over again.


3.     The manner in which the tree manipulation works seems kind of wonky to me.  I've been using it for a long time, but I'm getting to the point where I stop and ask, "Why does it do that?"  For instance:


Let's say I select the root node of my "Edit" menu which has several items under it, and I've got that menu open.  If I press the yellow, down arrow, the whole Edit menu relocates itself under my File menu.  The file menu is above the Edit menu!  Why does pressing "down" move the menu up?  Intuitively, I'd expect the entire Edit menu to move as a unit and appear after my View menu, exactly as it would if the whole "Edit" subtree was closed.  (This is hard to explain and I understand if my explanation is likely confusing.)


4.     When dragging and dropping tree nodes, there's no visual cue as to where the item will land.  You start dragging the node, mouse over the general area and cross your fingers.  Alternatively, you can eschew dragging and dropping altogether and opt for the yellow arrows of wonkiness.  Okay, in fairness the arrows are usually alright.


5.     I would really like to see Edit->Undo and Edit-Redo on this editor dialog.  Having to revert entirely and reopen the file can be frustrating.  Mistakes happen often, especially when dragging and dropping.


6.     This is less important to me than the other suggestions, but... is there any reason why the menu files couldn't be encoded in XML?  Right now they're not very text editor friendly.



Of course, as I offer these suggestions I intend no disrespect toward whomever developed the dialog - I'm simply perceiving room for improvement.


Thanks very much,



When a Preview or Dequeue has an incoming error, it return the default value of the data type. However, I think it could be useful for the Obtain Queue node to store the value of the data type that was passed in so that Preview/Dequeue can return that value on error. This shouldn't be a big complication to implement, and worst case it adds a memory overhead of sizeof(type).


Unless developers wired in a populated instance of a datatype, this shouldn't break previous code which depends on the default value of the data type in error circumstances.


Scrollbar for Cluster

Status: Duplicate
by Trusted Enthusiast on ‎12-06-2009 11:17 PM

I feel it is hightime that NI introduced the Scrollbar option for the clusters, similar to arrays.


This may serve as a workaround till NI implements the "View Cluster Constants as Icon" option, asked in another idea.

Status: Duplicate
This idea is a duplicate concept to the following idea post:

XY Intensity Graph

Status: New
by Active Participant Mads on ‎03-31-2011 08:23 AM

There seems to be a control missing in LabVIEW: an intensity plot that will accept data that has been sampled at a variable rate.


 It should be possible to specify the time stamps of each block in the plot (like with the XY Graph) so that you can present such data without having to resample it at a fixed rate. 

Being able to box things in w/o affecting the compilation of the program would make code clearer.

Using sequence boxes is not causing any problems for me, but it would be nice to have a proper structure.


Make inheritance graphically setable

Status: Duplicate
by Active Participant F._Schubert on ‎10-12-2010 06:25 PM

LabVIEW has a success story due to it's ability to program graphically. But the new LVOOP features still lacks the graphical touch. On the other hand, the text based SW is catching up with graphical modelling concepts as uml.


So instead of a simple config editor to set the inheritance, I request to have this completly graphical.

It's THE main feature of LabVIEW to do things graphically, so why fall behind this standard? No, not this tree control, but draw a wire to the parent, uml is already showing the way.

Status: Duplicate

Highlight Execution Should Not Disappear

Status: New
by Active Participant Manzolli on ‎05-05-2010 08:10 AM

I was quite surprised that no one wrote a suggestion about this yet, at least I didn't find after doing a search.


Sometimes, when Highlight Execution is on, you need to see a portion of the code that is not in the screen. Doing a scroll to see the desired code, part of the code being showed goes away, with the values shown by the Highlight Execution. If you bring back that portion of the code that was on the screen originally, the Highlight Execution values will not be there. You need to wait until next turn to see new values, or put probes in the wires to see then right away. Sometimes we need to see the FP or put any other screen over the BD. The result is the same, the Highlight Execution values will be gone.


The idea is to have an option to make the Highlight Execution values stick until you turn the Highlight Execution off.


Another interesting idea is to do implement the idea above and add a button to clear the Highlight Execution values anytime you want. Then the values could remain even after the execution being stopped. The advantage of this idea is that you will be able to edit the code with the values of the last execution on. May look messy, but you just need to press the clear button and all values will be removed, not a problem. With this concept it will be easy to save a screen (print screen) with Highlight Execution values on. Probably this also reduce the amount of probes needed in a daily basis.




Status: Declined
by Trusted Enthusiast on ‎04-10-2012 06:24 PM



                  I would like to be able to program the XNodes.





          Include the programming of Xnodes in labview features


                               ... for the next Christmas   clin d'oeil _ 1.gif





Status: Declined
XNodes are a proprietary technology that NI will not be releasing to the public

This is more of a bug report than an idea suggestion (although the boundary between both is sometimes tenuous).

When creating a Formula Node input or output variable, the name of a control or indicator created by Right-clicking the terminal is "input variable" or "output variable":




It should be named after the variable it is connected to. In the example above, I would expect "delta".

Shouldn't be difficult to do, the Mathscript node does things right:




PS: don't tell me I don't need to declare the output variables in the formula node. I know. I just created the latter for debugging purpose, which reminded me to post this overdue bug report.

Status: Completed

LabVIEW 64bit french version

Status: New
by Active Participant Mathieu_T on ‎09-21-2011 04:54 AM

A lot of customers are asking why a french version of LabVIEW 2011 64bit is not available. Is this idea take part of the future roadmap ?


Add New... to the RCM in projects

Status: New
by Proven Zealot on ‎04-05-2012 09:09 PM

OK, I've been working with some reformed txt programmers.  They like to decorate their vi names.  i.e ""  I've just about convinced them that the fully qualified name of " on Giszmo" is better but, it is not quite what they are looking for.


My Ctrl+Shift+T keyboard shortcut Launches File>>New...  Because it is not available from the RCM when selecting a folder in a project.  So if I select Funct.vit templates, create the vi and save it as Do Action in Giszmo project.  The displayed FQM is "Funct Do Action on Giszmo"


Perfect decoration!- since Funct(X).vit and Funct(y).vit tell me what type of action I indend to do! 


Here's where the story turns sad.  When I select a folder in a project and "Ctrl-Shift+T" the new vi is added to the project at root- Not at the selected folder.


This one seems like a no-brainer!


Adding last column number to Excel Get Last

Status: New
by Member mfattahi on ‎04-05-2012 07:51 PM - last edited on ‎04-06-2012 09:06 AM by Member MaryH

Currently NI_Excel.lvclass:Excel Get Last gives the last row in an excel worksheet. I am suggesting to add a last column count as well to the same VI.


Current NI_Excel.lvclass:Excel Get Last






Latest LabVIEW Idea Exchange Blog Posts
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 Kudoed Authors
User Kudos Count
Idea Statuses