Home > Community > 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

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.

Status: In Development

Wait (ms) with error pass-through

Status: Declined
by Active Participant MarcoMauri on ‎07-12-2010 05:01 AM


Maybe this has been already requested elsewhere and I'm missing it....

but it would be useful to have a Wait (ms) with connectors for error in and out.

This can help keeping the BD clean...



LabVIEW for Raspberry Pi

Status: New
by Active Participant vitoi on ‎07-16-2012 03:36 AM

The recently introduced Raspberry Pi is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).


The Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 15 times the processing power!


Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:




AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!


We need this:


 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.


 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

Here's how we currently make cluster element labels appear, and a proposed idea for improvement.


Status: Already Implemented
Available in LabVIEW 2012. In LabVIEW 2012 and higher, you have the ability to select multiple items on a block diagram (like elements in a cluster) and have a common right-click menu items available (like Visible Items>>Labels)

Same Height of Unbundle by Name / Terminal / Local Variable

Status: In Development
by Active Participant Andrey_Dmitriev on ‎11-02-2010 11:40 AM - last edited on ‎01-29-2016 05:14 PM by Trusted Enthusiast

The problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.

As result - aligning to vertical compress caused steps in wires:




Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.

Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)


Not sure if it was already in Idea Exchange or not.




Status: In Development
 When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls.  The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
Workaround:  Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons.  However not as convenient.
Status: In Development

I'd like there to be an option to show some kind of indicator on string controls that you aren't seeing the entire string. This should also apply to string constants on the block diagram.


Hidden String.png

I searched for a similar idea, but couldn't find one. Let me know if there is already a similar idea.

Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:




All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.


I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):




Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:




Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!

Status: In Development

Browsing through menus to replace a numeric conversion node is tedious.  How about allowing the selector tool to select from a pull-down menu, just like it does from an unbundle by name node?


Existing unbundle node behavior is shown at left.  Desired numeric conversion node behavior is to the right.



Smaller Event Ref Constants

Status: In Development
by Trusted Enthusiast Trusted Enthusiast ‎08-17-2010 04:22 PM - edited ‎08-17-2010 04:23 PM

The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.


Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!



Status: In Development

Include LabVIEW Version Number in Application Icon

Status: Completed
by Trusted Enthusiast on ‎10-13-2009 04:10 PM - last edited on ‎01-09-2012 03:34 PM by Active Participant JordanG

When you develop with multiple LabVIEW versions, it is sometimes difficult to identify which version you're using or launching based on the icon of the LabVIEW EXE:




Here's my Windows 7 taskbar with, among other things, LabVIEW 8.0, 8.5, 8.6, and 2009 icons.  Which one is which?  There are ways to tell, but it sure would be easiest if the version number were overlayed on the icon.  Note the Visual Studio 9.0 icon in the taskbar...I think we should do something very similar with the application icons of future LabVIEW releases.


NOTE: The icon should also reflect differences between the 32-bit version of LabVIEW and the 64-bit version of LabVIEW

Status: Completed

Implemented in LabVIEW 2014

Font size standardization

Status: In Development
by Knight of NI Knight of NI ‎01-05-2011 07:37 PM - edited ‎01-05-2011 07:42 PM

Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.


The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??


Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.


As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.


Idea -->LabVIEW should also standardize here!




Status: In Development

Integrated Structure Labels

Status: Completed
by Active Participant Hueter on ‎06-30-2009 06:11 PM

I think structures should have a better label system. Currently I use free labels of the same color as the loop which looks great and makes the code easy to read and debug. But if I resize my loop I have to manually resize the label as well. I think this should be built into a right-click option.


(structure) rick-click » visible items » Structure label


Integrated Structure Labels.PNG

Status: Completed
Available in LabVIEW 2012

Probes for Loop Iteration

Status: Declined
by Member Vinny_Burzi on ‎06-01-2009 08:48 AM

I would like the ability to probe the loop iteration terminal ("i" in For and While Loops) without the need to wire it to something (indicator, edge of structure,...).

Status: Declined
See AristosQueue's comment on page 2 for reasoning. Basically, systems would take a huge memory and performance hit to add this functionality. A lot of developers really like this idea so we will continue to look for ways to implement this in a way that wouldn't affect performance. This is not possible in the foreseeable future though (~2 years) so I'm moving this idea to declined for now but it will definitely not be forgotten.

Currently, the block diagram has an endlessly useful feature. I use it every day - the Distribute Tool.





The following feature would be AWESOME for expediting BD readability:



Status: Completed
Available in LabVIEW 2011

Reduce the size of the Close Reference VI

Status: New
by Member ReneW on ‎05-13-2011 01:58 AM - last edited on ‎05-13-2011 08:56 AM by Active Participant Laura F.

The size of the Close Reference VI makes it impossible to draw a proper block diagram.



It is too big!  It does not match with the Property Node vi.


Therefore I would propose: --> Make the Close Reference VI smaller!


Truncate Long Paths

Status: Completed
by Active Participant blawson on ‎02-15-2010 10:10 AM

I don't like the way that long file paths are shown in path controls and indicators:  If the path is longer than the textbox (and it usually is!), the user only sees the first several levels that fit.  This can be pretty confusing.


One way to solve this issue is to truncate the path in the middle in such a way that the filename or last folder (which is usually what's most important) is always shown.  I've seen this in other UIs and it should be a natural thing for users to understand.


Here's an illustration:



I think this should be a built in feature of the path controls and indicators, accessible through right-click menus and/or the properties menu of the control at edit time.

Status: Completed
Available in LabVIEW 2012



When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:




Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:




To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):




The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.




Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog.  The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu.  I can't think of one time when this has ever been what I wanted out of this action.  Instead, I think this action should open up the VI Properties Window for the VI.  



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!
Idea Statuses
Top Kudoed Authors