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

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.




The "Probe Display" pane of most default probes should have indicators that are set to "Fit to Pane". The worst offenders, in my opinion, are Strings and Variants...I often find myself cursing the fact that I can't see more of the data, and usually have to copy & paste into Notepad++ or something to actually see what I'm looking for.


Yes, you can make custom probes for this behavior. But it should be native.



 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.


Change the Path Type function output from a signed 16-bit integer to a text ring or enum to aid immediate readability of code and save having to look at the help file:


LabVIEW_2018-11-05_09-16-13.pngThe Path Type function returns a signed 16-bit integer indicating the following 3 types of paths.

0: Absolute path

1: Relative path

2: <Not A Path>


LabVIEW_2018-11-05_09-26-34.pngUnhelpful context help.


Text ring would have the least impact on existing primatives:

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!



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!




Not so much an idea, as a wish/plead/rant:


Please make the next version of LabVIEW a major update of the features we have available to create user interfaces.


2011 was the "improved stability" version. 2014 should be the year it became simple and fun to create user interfaces that blow everyone's socks off. I'm not even talking about fancy stuff, just get the basics right!  Fix the graph indicators, and provide better front panel scaling options - and that alone will make 2014 the best update ever(!).



I started writing a list of all the things I find bad with the graph/charts for example, and found out that it would be better to just do a search here on the idea exchange to see how many ideas mention graphs alone. 2390 ideas! (yes, I have not gone through them all to filter out the ones that do not actually request changes to the graphs, but most of them do, directly or indirectly...). My own little list started like this, in random order:


Graphs and charts

1. You cannot stack plots in any of the graph indicators, only in charts
2. Number of plots stacked cannot be varied at run-time
3. Annotation properties are only partially available programmatically
4. Auto-scaling cannot be restricted to one way-only, it's behaviour cannot be configured in any way
5. Legends, palettes and tools do not fit together to form an organized user interface, nor are they possible to detach from eachother to get more flexible designs/scaling for ecxample...
6. XY graphs become sluggish and almost unusable with large data sets, where alternatives written in other languages have no performance issues
7. Plot colors could automatically adjust to the chosen background color - suggesting unique colors for the added plots that provide the best possible

8. Graphs on e.g. Google and Yahoo have tonnes of cool features like animated zooming, thumbnail graphs, highlighting of the plot you hover the mouse over etc. which provide a very interactive feeling, you can achieve some of this in LV as well, but it could/should be possible with little or no programming

9. To get charts to accept data with variable sample rate (delta X) is possible, but cumbersome and an almost hidden feature...


Mixed signal
1. You cannot set the group names programmatically
2. The number of plot areas is not configurable at run-time
3. You cannot assign plots to a given group programmatically
4. You cannot show the visibility checkbox of each plot etc.


And then you have the additional 2000 ideas...;-)


As for front panel scaling there are not that many ideas (naturally), but the impact/value of them would change every LabVIEW programmer's life significantly. We can stop spending so much time finding ways around limitations in LV, and start focusing on the actual goal of our applications.

Would that not make everyone's day?




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!

The title says it all: The property dialog of controls should allow inspecting and changing the default value.


Here's how it could look like.



Sometimes I wand to re-define a default value without actually changing the current value.


current steps

  • copy the current value elsewhere
  • enter the desired default value
  • operations...make current value default
  • restore the original value (could lose data in case of DBL!)

After implementing the idea

  • default value...OK.




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

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.

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

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:



The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk.


We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!)


I would like to request a feature that allows us to easily and permanently remove any entry in the list.
(...maybe it could even show for pinned entries?)


IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list.


It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry.


These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.

Currently text in an "unbundle by name" node is centered. This makes for poor readability when there are several elements being unbundled.




I think that changing the justification from center to left does improve readability.


Left Aligned.png


Note 01: This apply to bundle by name as well.

Note 02: implementing this idea my gave us this one for free.

There's a common convention in LabVIEW where if a control is not a required input, you place the default value in parentheses:




 For the most part this make sense and is useful when calling VIs, but there is one place where it's really annoying:






We know there's no error by default. I suggest that NI simply remove this. This can be done today by going to <vi.lib>\errclust.llb and modifying the control, but that's annoying to do with every installation.


I would even go so far as to say that NI should write a VI which will go through vi.lib and remove the text from all the existing VIs. I doubt this would have any backward compatibility issues, because I think the only place where those would be relevant is if someone is calling a VI in vi.lib dynamically AND setting the error in value, and frankly, those people deserve to be punished.



NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.


I suggest that NI start shipping USB keys instead. USB has several advantages:


  • USBs are smaller
  • USBs are more usable on devices without DVD player
  • Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
  • USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.


Ship developer suite on NI USB keys

It has come up in discusssions that NI does not really cater to hobbyists. A cheap and functional version of LabVIEW is limited to the student edition, which is restricted to a small subset of potential users.


 From the  FAQ:

"The LabVIEW Student Edition is available to students, faculty, and staff for personal educational use only. It is not intended for research or institutional use."


As a suggested first step, I suggest to remove the academia restriction and mold it into a new product:


--- LabVIEW personal edition ---


Licensed as follows:

"The LabVIEW Personal Edition is for personal use only. It is not intended for commercial, research or institutional use."


 It would be available to anyone for noncommercial home use.


LabVIEW currently has the home use exemption that allows installing a copy at home. Unfortunately, if you lose your job, you not only lose your health insurance, but you also lose access to LabVIEW, thus hampering any self paced LabVIEW tinkering that possibly would improve future job prospects. I am sure many retired LabVIEW engineers would love some recreational LabVIEW use. They could be a great asset, because they will have more time helping out in the community and forums. They could even give guest presentations at user group meetings, for example.


The LabVIEW personal edition should include all modules of interest to the hobbyist, including application builder, embedded, FPGA, and robotics.  We should be able to distribute built applications as freeware. Support would be limited to community support.


Installing LabVIEW on every single private home computer in the world would cost NI exactly nothing (except for some sales of the current student edition which is about the price of a textbook, some internet bandwidth, and loss of the zero to two (?) multi-millionaires who actually bought the NI developer suite for themselves. Smiley Wink). 99.9% of users would never touch it, but that 0.1% could come up with great new application areas and would help spread the word on how great LabVIEW really is. Soon 0.2% would use it. Smiley Happy


It should follow the "customer class limited" Freemium model, (as defined by Chris Anderson), i.e. limited to personal home use in this case.


The running applications should be clearly identified to prevent commercial use. The splash screen and "about" screen should prominently display the words LabVIEW and National Instruments and could even be used for NI advertising and product placements, for example.



As soon as we have more complicated data structures (e.g. clusters of arrays), a large portion of the FP real estate is wasted taken up by borders, frames and trims, etc.


We need a palette full of "Amish" Smiley Wink controls, indicators, and containers that eliminate all that extra baggage. We have a few controls already in the classic palette, but this needs to be expanded to include all types of controls, including graphs, containers, etc.


A flat control consists of a plain square and some text (numerical value, string, ring, boolean text, etc). A flat container is a simple borderless container.  A flat graph is a simple line drawing that would look great on a b&w printer. A flat picture ring looks like the image alone.


They have a single area color and a single pixel outline, if both have the same color, the outline does not show. They can also be made transparent, of course. If we look at them in the control editor, there are only very few parts.


Now, why would that be useful?


Let's have a look a the data structure in the image. There is way too much fluff, distracting from the actual data. If we had flat objects, the same could look as the "table" below. Note that this is now the actual array of clusters, no formatting involved! It is fully operational, e.g. I can pick another enum value, uncheck the boolean, or enter data as in the cluster above.


Many years ago in LabVIEW 4, I actually made a borderless cluster container in the control editor and it looked fine, but it was difficult to use because it was nearly impossible the grab the right thing with the mouse at edit time.


The main problem of cours is that the object edges completely overlap, making targeted seletion with the mouse impossible. (For example the upper right corner pixel is the corner of an array, a cluster, another array, and an element at the same time.)


So what we need is a layer selection tool that allows us to pick what we want (similar to tools in graphics editing software). It could look similar to the context help shown in the picture with selection boxes for each line. Picking an object would show the relevant handles so we can intereact with the desired object. Another possibility would be to hover over the corner and hit a certain key to rotate trough all near elements until the right element is selected, showing it's resize handles. I am sure there are other solutions.


As a welcome side effect, redrawing such a FP is relatively cheap.


Message Edited by altenbach on 06-03-2009 09:20 AM
Message Edited by altenbach on 06-03-2009 09:20 AM