NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

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

Many LabVIEW functions use the UI thread, like DataSocket (due to ActiveX events IIRC), everything VI Server etc., and since there is only one UI thread (per LV instance, no matter the number of logical processors, right? Also on Real-Time?) these functions are blocked when the UI thread is occupied by something else.


What I find particularly troubling is the fact that you can't dispatch VIs dynamically when the UI thread is blocked - for instance if a dialog is open or a user is selecting something in the menu. The latter can be an application blocker, if you are dispatching 20 VIs to populate your UI for example, and the user clicks the menu bar (without selecting something), your app might freeze since you won't be able to dispatch anymore VIs until the user lets go of the menu bar. There are many much simpler scenarios that you'll hit more often (a DataSocket read with a long timeout may block your dynamic VI from loading?).


Upping the count of UI threads from one to several would be great, but probably out of the question due to the implications to the LabVIEW core.


Instead, could we at least get the 'Open VI Reference' function and the 'Run VI' VI Server method freed from the UI thread? That would enable dynamic dispatching while the UI thread is blocked. Other VI Server calls aren't that important to get out of the UI thread, since there are other (and better) ways to transfer data to your dynamic VI for instance, than with VI Server. One curious thing is that it's possible to open all the 'One Button Dialogs' you want in parallel for instance - I'd think they'd run in the UI thread, and hence the first one'd block the rest?


A (somewhat contrived) example that fails due to this limitation:



The blue statement is true even when DynVI doesn't touch the UI thread, and even when no VI in the hierarchy runs in the UI thread etc. It's simply the 'Open VI Reference' primitive and the invoke node that gets blocked, due to the one button dialog being open.





Additional glyphs for project explorer

Status: New
by Active Participant Daklu on ‎09-12-2009 08:29 AM
I like the glyphs in the project explorer window that indicate the scope of each vi.  I would find it extremely helpful if glyphs were added to indicate a VI's override status.  (Must override, overrideable - normal dynamic dispatching, and not overridable - static dispatching)

Path to recycler or function "recycle"

Status: Duplicate
by Member mawodorfer on ‎11-30-2012 03:48 AM

Sometimes I do not wish to delete a file permanently or keep the path of the delete file for later restore. Usually this is done in Windows by sending the file to the recycler and getting it back from there.


Two possibilities to get this functionality into LabView:

- Add "Recycler path" to the VI "Get System" to return the path to the recycler. The file can than by moved to the recycler and eventually back again

- Add a new VI "recycle" to the files palette. It should work like the "" and return the path to the recycled file in the recycler.



Status: Duplicate

Local/global/Shared variables or properties nodes (that are read/writeable) are usually placed in read mode.


For Power users it would be great if by holding e.g. the Strg.-Key the local variable or properties are placed in write mode. Also a good idea would be that the node adapts to the wire (input or output), but this idea is already in the idea exchange.

When you use a case statement, the situation arises where in a particular case there is no need to pass an object to an outbound tunnel, while in other cases you do in fact want to pass an object out the tunnel. To keep Labview happy, you must either provide a bogus item to the tunnel, or you can set the tunnel to "Use Default if Unwired".


I *hate* "Use Default if Unwired" because once set, if you simply forget to wire a tunnel, you will not get an error indication telling you that you screwed up.


I do however have a suggestion for how to resolve this:


1. Rename "Use Default if Unwired" attribute to "Use Default if Unwired (all cases)".


2. Add a new tunnel attribute "Use Default if Unwired (this case)". This will cause the tunnel to pass the default value if a tunnnel is unwired,  but only for the case you set it in. In that way you suppress Labview complaints for cases where you explicitly don't CARE what is passed on, and will still get complaints if you forget to wire to the tunnel in one of the other cases.


3. Add a new tunnel graphic for the new "Use Default if Unwired (this case)"  attribute to differentiate it on the block diagram. Use the existing graphic for the "Use Default if Unwired (all cases)" option.  


4. When you set "Use Default if Unwired (this case)"  on a tunnel, Labview should check to see if  "Use Default if Unwired (this case)"  is set in all  other cases for the same tunnel. If so, have a dialog pop up to ask if you want to convert to "Use Default if Unwired (all cases)". But don't set  "Use Default if Unwired (all cases)"  by default; ask.  You might be adding more cases later...


5. The "Use Default if Unwired (all cases)" and  "Use Default if Unwired (this case)"  attributes are mutually exclusive. If you select one, the following behavior occurs and the other is de-selected:


  • If you set "Use Default if Unwired (all cases)" at any time (including in the dialog box above) , then "Use Default if Unwired (this case)"  should be cleared for the tunnel for ALL cases in which it was set, keeping things consistent.


  • If you set "Use Default if Unwired (this case)" at any time on a tunnel in a specific case, and  "Use Default if Unwired (all cases)" was previously set for that tunnel, ALL cases must be changed to "Use Default if unwired (this case)". The behavior of your code then remains unchanged, except that you can now selectively clear "Use Default if Unwired (this case)" for any case in which you don't want it set for that tunnel.

See the attached picture to see how the current and proposed behavior differs, and to get a look at what the implementation might be.


Display VI version in Tools bar For any vi

Status: New
by Active Participant jwdz on ‎10-14-2010 08:04 AM

Display VI version in Tools bar For any vi




My use LabVIEW 2010,Often saved a vi(8.5) as high-version .


Alternatively, when saving the vi, the programmer could be proposed to choose the former LV version.


Sorry ,My English no good.

My suggestion is a change to the UNDO function.


A common annoyance is when making a large number of changes to the block diagram that fundamentally alter the way a VI works and then you go to the front panel and set up a few default values before you press play. You then find that the code doesn't work anymore so you then try to undo the changes... You then find that the undo only undoes the changes to the front panel and not the code that really matters. not you have to manually recode what you had before or reload from disk (hopefully you haven't saved yet)



My proposal is to have 2 separate undo functions - One for each edit screen ie Block diagram, and front panel.

see the diagrams below.. the shortcut keys can be differet - this is just an example and it could be implemented differently. also an icon could exist on the menu.

Block diagram UNDO.png.


Likewise for the Block Diagram


Block diagram UNDO.png




Here are some options to consider:

Method one.

The UNDO function will work differently depending whether you are in Front page view or Block Diagram view. - but the global undo functions the same as it always has.

Method 2.

Have the UNDO function work differently regardless whether you are in Front page view or Block Diagram view - but you must press the correct button on the menu or shortcut keys (ie CTRL + Z + F for front Panel or CTRL + Z + B for block diagram) or CTRL+Z for Global UNDO which will function the same as always.

Method 3.

Don't have a Global UNDO - and instead the UNDO button will only UNDO the changes on the front Panel or the Block diagram depending on what view you are currently in.


Perhaps these options could be set under "tools/options" etc - not sure what tab would be best.


I favour Method 1 or Method 2.

Note: the CTRL + Z + F for Front Panel and CTRL + Z + B for Block diagram is just a suggestion. but something similar should work...and likewise for the redo functions..


Hopefully this is clear.



Finer control of password protection

Status: New
by Member candidus on ‎02-02-2012 05:01 PM

Did you ever want to add a password-protected VI to a library or use it independently from that library? You can't do that because the password protection of the VI also forbids you to change its membership in a library.
Viewing/editing a VI and adding it to or remove it from a library are different things, however:

Imagine the following situation:
I prefer to organize my projects using lvlibs and lvclasses. Many third party libraries still come as llbs or even plain VIs. I'm not supposed to have passwords for these libraries. But these third party VIs cause naming collisions in my project. All I want is to put these things into lvlibs to prevent name collisions or build a packed
library for reuse in my projects.

Membership is not necessarily implementation hiding and thus should be treated differently. The VI's vendor should have the opportunity to decide whether changing library membership is allowed, independently from locking the block diagram.


A modified VI security properties dialog could look like that:




A VI with these properties is password protected but can be moved freely between libraries.



Selectable Class Data Member Scope

Status: New
by Trusted Enthusiast on ‎10-12-2010 07:39 PM

Currently, a class is created with a Class Private Data Cluster. Each data member of that cluster is scoped exclusively to the owning class. For access to these data members outside class member VIs, getters and setters (accessors) must be established individually for each element. These accessors can then be scoped accordingly, allowing access to the private class data through the accessor VI, or in 2010, through an accessor Property Node.


Quite frankly, I like the IDE interface for accessing class data members using Unbundle/Bundle by Name. This feels natural for LVOOPers who have a background with clustered typedefs (which means everybody). Unfortunately, this method of data access is reserved for callers within the scope of the class data. Currently, since all class data is private, you can only use Unbundle/Bundle within Class Member VIs themselves.


I would suggest an options interface for setting the scopes of Class Data Members. Having non-private data member scopes has benefits:


  1. Obviates all the piddly accessors clogging your project tree and SCC server
  2. Allows quick visual recognition that a data member is being read/written directly (no data transformations were snuck into the accessor)
  3. Cleaner interface for callers of the class using the Bundle/Unbundle
  4. Best of all, saves considerable development and maintenance cost
Here's an example of what the Data Member Scope Configuration screen might look like:
Note that clusters can have "Custom" scope, which means the cluster's elements have different scopes. Also note that when a cluster's scope is set explicitly, it's members inherit the same scope and cannot be set (note how 'x' and 'y' are greyed under 'Center of Mass'). The default behavior (which is equivalent to today's default scope) is for 'Class Data Cluster' to be 'Private' with all descendants greyed.
This Idea is one product of a discussion which has taken several routes.



The deletion of a Conditional Disable Symbol has no effect on the Conditional Disable Structures which use it.


This is very dangerous because the Conditional Disable Structure ignore the deleted conditional disable symbols and the default case is used.


It should be nice, in case of Conditional Disable Symbols deletion, to make "unexecutable", all Conditional Disable Structures which use it.


Thanks for reading.




Hi All,


I have recently encountered some problems when using libraries in my code whilst needing/wanting to disconnect multiple VI's from that library. I have found the process of manually selecting the VI's for disconnection to be rather tedious and time consuming (especially if they have enums and subVI's associated with them), I would suggest that perhaps the option of "disconnect all VI's from library" could possibility. After a brief discussion with some of my colleagues, some of which are very experienced developers, I have found they are reluctant to use them for this and various other reasons. I have managed to find a workaround for the solution on LAVA with this handy little script. I was surprised this functionality was not included in the development environment. Any input from other users with regards to the pro and cons they have encountered when using the libraries and other suggested workarounds would be greatly appreciated. Thanks!

I'd love to see a handful of built-in false-color colortable choices for the Intensity Plots.


I know there's programmatic control over these things - I wrote my own 4-5 years ago. But the black-blue-white should be one of several common selectable colorschemes.


I labeled my own as:

 Greyscale B->W

 Greyscale W->B


 Yellow Hot


 Rainbow #2

 Fluorescent (green)

 Blue Red Green 

 Planet Earth


Perhaps one of the front panel (and Property node please) off of the Z-Axis submenu, listed by title.


I also have the ability to invert top/bottom or choose the color-inverse (photographic negative) for even more colors. 


Attached is a sample of some common colortables I routinely use.

2nd attachment is a snap of the VI I use to create the colors based on colortable constants.

3rd attachment is my messy but functional code (Block Diag of attachment 2)



3D scatter plot

Status: New
by Active Participant Cory_K on ‎10-06-2010 08:26 AM

Rather than a surface plot, it would be really nice to have a 3D scatter plot.

Right now, you have to pass a 1D x-array, 1D y-array, then a 2D z-matrix.

This is very non-intuitive, and takes quite a bit of poking around to figure out why this is the case.


It would make much more sense to be able to pass in a cluster of 3 1D arrays of equal length, the same way you do with an XY graph.

In this case, it would be an XYZ graph.


List the lvlib hierarchie

Status: New
by Active Participant EricC. on ‎05-19-2011 04:03 AM

In a complexe project, when you make Packed Librairie (lvlibp) or dll it is very important to compil your lvlib in a good order.

(from lvlib with less depencies to lvlib with more depencies)


But we don't have a way to see the lvlib hierachy

(we have only vi hierarchie, class hierarchie)



Option for turning off indexing for TDMS

Status: New
by Member Gleichman on ‎08-26-2009 03:42 PM

" ... when a TDMS file is open, LabVIEW will create an index structure in memory that is used for random access to the file. The built-in LabVIEW TDM Streaming API will always create this index, even if you're just writing." - Herbert Engels

This feature will cause an apparent memory leak if your program periodically writes to a TDMS file over a long period of time. 


Feature Request: 

Disable indexing option for "TDMS"

It's very rare for me to deal with large arrays, so it's seems very retarded when I'm debugging to 

find VIs have not retained their values. I must turn on the "retain values" and re-run and go through 

a huge test sequence again to trigger the problem.


All to save 100K of memory, when I've got 2G to through around.


How about a global setting "RETAIN WIRE VALUES" and per-VI setting to override the global.


Wouldn't take much...



I'd find it really helpfull, if there would be a possibility to create a new "value change" case in a event structure by right-clicking the control-terminal in the block diagram. If there is no event structure in that VI, the menu entry ("Create event") should be greyed out or be removed.

I could create cleaner diagrams faster if I had an option on the output tunnel of a case structure to use previous value.



When debugging an xcontrol it is annoying to constantly go back to the xcontrol .xctl window and to unlock the library for editing by right clicking on the .xctl icon and selecting it from the drop down menu.  I usually have lots of windows open for debugging and finding the control window, and then right clicking and selecting can get tiresome very quick.  It would be nice if vis that were a member of the xcontrol had a button, perhaps next to the context menu button, that you could click on for unlocking the control for editing, and similarly the converse, applying the changes to all instances.

Today if you want to change for example a number of controls to indicators or constants you have to do it one by one. The only option you get when selecting multiple controls and right-clicking is "Properties"

Multiselect Props.png

Wouldn't it be nice to be able to change multiple at a time?


Multiselect Props.png


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
Idea Statuses