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 Kudoed 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

It would be nice if the Error Ring would accept enums.

Enum in Error Ring.PNG

So the Error Ring does not accept an enum (A). Format Into String does (B). So now we need the extra step of putting a Format Into String before the Error Ring (C).


This would be more convenient in for instance state machines (D) or functional globals with a function enum.


While on it %s on FIS also accepts Booleans. Nice to have the error ring accept them as well, just for completeness.

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.



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.

Hi guys,

I'm missing some very fast way how to create cluster out of selection. It could be done as it is shown here:


create cluster.png


I think since LV developers became familiar with Every GUI Programmer's Dream they are ready for the next step...

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.

With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.


For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.


For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.




Not a duplicate of


[admin edit: Adding animation image at the request of the OP]


Resizing the front panel so it is correct when running the VI is still very tedious and can easily mess up during editing. The problem is even more severe for Xcontrols, because their runtime size is often very small so there is not even enough room to e.g. display all the tools in the tool bar during editing. Once the runtime size is correctly set, all it needs is a double-click on a terminal that has its FP item hidden outside the visible area and everything on the FP shifts and messes up.


We need three things:

  1. An "edit time" FP size that is "comfortably big" so we can see the entire toolbar and possibly also helper controls and even maybe some comment text intended for the programmer that are outside the operator area and only used for debugging and such.
  2. A "run time" FP size that matches exactly what the operator sees during running.
  3. A special decoration or other visual cue during editing that indicates the FP area that will be visible at runtime.

 We already have the crosshair in the upper left corner when showing the grid, so that could be defined as the upper left corner at runtime by default. All we need is define the upper left and lower right corner and the runtime FP area is uniquely defined. As a visual cue, everything outside the runtime area could be a shade darker or tinted differently than normal to indicate that fact. Running the VI would snap the FP boundaries to the bright area.


Then we also need handles to move any of the boundaries at single pixel increments. A control that scales with the front panel would simply scale to the bright area instead. Of course a legacy mode for older VIs that did not have this feature during their creation needs also to be supported.


The example image shows a reddish transparent area (just to throw out another idea, maybe a slightly darker grey would be better). This is one of my own subVIs that demonstrates the problem at hand. At runtime, only the progress bar should be visible, while at edit time, I want to see all controls, because I might need them e.g. to wire the connectors. It is not easy to switch between the two sizes.


(Of course we can currently program around all that by setting windows parameters via property nodes, but it is ugly, inefficient, and tedious.)




When you connect the error wire to a case structure selector, you get two cases for error and no error. I think you should be able to add in cases for specific error numbers so you can handle specific errors differently. You could do this currently, but you would have to unbundle the error and use the error code.


Numbered error case.png

It is not obvious that a NaN numeric constant can be created by simply typing "NaN" as value. What we see are weird constructs, e.g. "zero divided by zero" or "square root of -1" to generate a NaN on the diagram.


I suggest to add a NaN diagram constant to the numeric palette to make it more obvious.



(This is just a quick draft. Of course it should be matched in color and design to the other constants)

(As already hinted here, I think this deserves a seperate idea).


Property nodes have many items that accept color data (cursor color, plot color, bg color, etc). When right-clicking these and "create constant|control|indicator", we get a generic U32 type. Instead, we want a colorbox! Even more complex color structures, e.g. (colors[4] of a boolean) should have colorboxes as the innermost elements.


In all instances I have ever used these properties, I ended up replacing the U32 with colorboxes for code readability and simplicity.


Idea: when creating an input or output (constant, control, indicator) on any color property, we should get a colorbox (control, constant, indicator) instead of a plain U32 numeric. 



I would love to be able to draw a box over a bit of code on the block diaghram and be able to highlight execution just for what's in the box. The rest of the code should execute at full speed. This frequently becomes an issue when you are trying to track down a bug in a big program and you've got to wait for ages to get to the bit your interested in.

Another for the wish list.


It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).


The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.


See attached pic for an mock up.

case glyphs.PNG

 There are probably lots of menus that could benefit from something like this.


Whenever we create a constant (or control) on a partially connected function, we get not only the same datatype (good!), but also the same array dimensionality (often not so useful).


In the vast majority, I want do do some uniform operation on the entire array, so a scalar control or diagram constant would be much more desirable. I usually end up creating the array constant, then pulling it out of the container, hook it back up, and delete the container. This guarantees the correct datatype (I32, DBL, CDB, etc).


(It is even more tedious to place a diagram constant from the palette and then remember the datatype and adjust accordingly).



When creating a control or constant, and it would result in an array, I would prefer to also have a scalar option.


This little move illustrates it in the case of creating a diagram constant. It should apply equally to controls.



Message Edited by altenbach on 07-11-2009 09:51 AM

LabVIEW  has a somewhat hidden feature built into the variant attributes functionality that easily allows the implementation of high performance associative arrays. As discussed elsewhere, it is implemented as a red-black tree.


I wonder if this functionality could be exposed with a more intuitive set of tools that does not require dummy variants and somewhat obscure VIs hidden deeply in the variant palette (who would ever look there!).


Also, the key is currently restricted to strings (Of course we can flatten anything to strings to make a "name" for a more generalized use of all this).


I imagine a set of associative array tools:



  • Create associative array (key datatype, element datatype)
  • insert key/element pair (replace if key exists)
  • lookup key (index key) to get element
  • read all keys
  • delete key/element
  • delete all keys/elements
  • dump associative array to disk
  • restore associative array from disk
  • destroy associative array
  • ... (I probably forgot a few more)
I am currently writing such a tool set as a high performance cache to avoid duplicate expensive calculations during fitting (Key: flattened input parameters, element: calculated array).
However, I cannot easily write it in a truly generalized way, just as a version targeted for my specific datatype. I've done some casual testing and the variant attribute implementation is crazy fast for lookup and insertion. Somebody at NI really did a fantastic job and it would be great to get more exposure for it.
Example performance: (Key size: 1200bytes, element size 4096: bytes, 10000 elements) 
insert: ~60 microseconds
random lookup: ~12 microseconds
(compare with a random lookup using linear search (search array): 10ms average. 1000x slower!)


The 64-bit version of Database Toolkit hasn't been release yet and the usage of 32-bit version with LabVIEW 64 isn't officially supported.

I think it's time to release it...

I'd like to suggest that the error ring dialog ("Select Error") have an entry for a search expression.


For instance, I'm looking for an error code for an index out of range.  I might enter, "index" or "range" as the search term, and browse the resulting error codes whose descriptions include that text.


While I don't find myself using the error ring itself very often, I do use the resulting dialog quite a bit to browse for appropriate error codes.  The trouble is that there are a lot of error codes and you could be staring at them for quite a while looking for the right code.




Mr. Jim





I searched for this one and couldn't find it.  Apologies if it's already been posted.




Suppose that we want to start coding my Real-Time application, but the hardware hasn't arrived yet.


We can't Discover the chassis + modules, so we need to add modules manually.



Current editor



To add N modules, we need to launch this dialog N times:


  1. Right-click on Chassis in the Project Explorer
  2. Hover over "New"
  3. Click "C Series Modules…"
  4. Click "New target or device"
  5. Click "C Series Module"
  6. Click "OK"
  7. Wait for LabVIEW to fetch module list (wait ~1 second)
  8. Select Type (2 clicks)
  9. Select Location (2 clicks)
  10. Click "OK"
  11. Go to #1 to add a new module


How tedious!



Proposed Editor

Wouldn't it be nice if we could set up all the modules in 1 dialog?





  • Table auto-fills itself with modules already in the project
  • Number of rows is determined by the chassis model. No need to select Location
  • Ability to leave rows/slots empty
  • Editable Name field (with default name) appears upon selecting Type
  • Description appears upon selecting Type



Feel the difference

Adding N modules (using default names) requires...

  • Current dialog: 10N clicks, N hovers, waiting N seconds
  • Proposed dialog*: (6+2N) clicks, 1 hover, waiting 1 second


So, adding 8 modules requires...

  • Current dialog: 80 clicks, 8 hovers, waiting 8 seconds
  • Proposed dialog*: 22 clicks, 1 hover, waiting 1 second

*Assuming that steps 1-7 and 10 need to be performed once


Labview 2013 has a great new documentation feature called Bookmark Manager.  It even has a nice feature that lets you click on the listed bookmark and takes you to that point in the code. However, I was surprised that I could not print or otherwise "export" the list.  It would be nice if the Bookmark Manager output list savable, copyable and printable or perhaps even exportable in text, spreadsheet or other format.  This would allow the information to be merged with external project management schedules, ToDo List etc.  Thanks for any comments and/or Kudos!!


Bookmark Manager Suggestion1.png

A pretty common use case of LVCompare in my workflow is to use it as a diff tool in SVN to compare different versions of a VI. When I do that, the previous version is downloaded into a temp directory, and then there is a decent amount of load time because dependency paths have to be resolved differently for the version in the temp directory and some recompiling happens. For top-level VIs in large applications, it seems like the whole dependency tree is getting loaded, which takes a long time. But really, for comparing VIs, there's no need to load the contents of lower level subVIs (and their dependencies, and dependencies of dependencies, etc.) As long as the connector pane, typedefs on the connector pane, and the icon of a subVI are loaded, that should be enough information for a visual diff of the top level VI.