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

Control reference Size improvement for space saving

Status: New
by Member PBP on ‎05-26-2015 10:27 PM

HI This idea may be addition to THIS.


PBP should propage "NaN" values

Status: Declined
by Member ec01 on ‎05-27-2015 06:58 AM



now the percentile VI calculate a table with NaN-values as the NaN-values are numbers higher than +Inf. This is incorrect.


The percentile VI should propage to result NaN if one of the elements of the table is NaN.

(An other solution is not consider NaN values and return as result the value greater than p percent of the data values in the array, but it would create incoherences with all other VI which propage the "NaN value")


Here a screenshot of the a bad response of this VI.


Status: Declined

Moved to CAR database: CAR 529474

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

Right-click: Adapt Output Indicator to its wire

Status: New
by Member Enrico_Segre ‎05-25-2015 03:44 AM - edited ‎05-25-2015 04:03 AM

I'm very often in this situation:

Screenshot from 2015-05-25 11:18:57.png Screenshot from 2015-05-25 11:18:49.png


At some point I realize that I have to change somehow my output indicator, say adding an array dimension, changing an element type, adding a cluster element, whatever.


Screenshot from 2015-05-25 11:22:22.png


Well, if I could just right click and choose "Adapt Indicator to wire"....


My current best general workaround is the following:


  1. Go to the wire source (may be far away on the BD) and right-click "Create Indicator"
  2. Select the newly created indicator and double click it to select it on the FP
  3. Ctrl-X cuts the new FP indicator
  4. Select the old indicator on the FP (or go back to BD, double click...)
  5. Ctrl-V replaces the old with the new indicator but leaves it on connector
  6. Go back to the BD and rewire to the proper source/ remove broken wires

If the indicator I wanted to modify was, additionally, Hidden, there are a couple of steps more of Show/Hide... And if instead I invested in cosmetics of the indicator, I have to redo that again from scratch...

Make Boolean Wires easier to see

Status: New
by Member Ken_Naylor on ‎05-15-2015 05:46 AM

When the Grid is on it is difficult to see Boolean wired due to their 'dotted' appearance.


Change the Boolean wire from a dotted green line to a solid green line to improve visibility


LabVIEW wires.JPG






Clear Errors Polymorphic Inputs

Status: New
by Trusted Enthusiast on ‎05-04-2015 07:51 AM

In 2014 the Clear errors VI now accepts a single error which can be cleared.  This is nice but when I heard NI was implementing their own filter errors, I assumed they would do it in a similar way to the OpenG Filter Errors VI, which accepts a scalar, or an array of error codes to filter.


In addition to this I think it would be helpful if this Clear Errors also accepts the error data type for errors to filter, or an array of errors to filter.  That way the Error Ring can be used to help readability of the block diagram showing the error that is being cleared.


Improve Clear Errors Filter.png

FPGA timing functions with better labels

Status: New
by Member TDPero on ‎05-13-2015 11:44 AM

When programming in FPGA, all the timing functions are polymorphic, meaning you have to configure it for either ticks, us or ms. If your not carefull, this can sometimes lead to unwanted error due to simply overlooking a wrong configuration, as in the following example picture:


How are the timing functions configured?


I propose a simple indicator or different icon to easily see the difference. Something like this, only maybe better looking:

Proposed solution

Let the user choose the probe location on a wire

Status: New
by Active Participant X. on ‎04-24-2015 08:13 PM

Ther are 10 pages of suggestions coming up when typing "probe location on wire".

AFAIK, none of them addresses this irritating behavior of probes:


Screen Shot 2015-04-24 at 18.07.18.png


The probe icon will snap to some algorithmically determined location which might result in illegible data flow during debugging, or might end up in a region of the diagram far from where the critical action takes place.

I know that what matters should be the VALUE of the probe, but WHEN to check the probe value is also critical, and in a visual development environment, this time is determined by monitoring the data flow (among other methods). This is where this uncontrollable probe location can be annoying at times.


My suggestion: just as for labels, let the user choose the location of a probe anchor point on a wire (especially when it branches off).

Close Project

Status: New
by Trusted Enthusiast on ‎03-21-2015 02:03 PM



  It would be very usefull to know which VIs are still running.


Bundle/unbundle split and merge

Status: New
by Trusted Enthusiast on ‎04-29-2015 04:33 PM

I hope the picture speaks for itself.




Extend File I/O Functions to Mirror OpenG

Status: New
by Trusted Enthusiast ‎05-19-2015 07:37 AM - edited ‎05-19-2015 07:39 AM

This idea is not to take the awesome OpenG functions and make them native.  This idea is to take the native functions that exist today, and extend the functionality to mirror the OpenG equivalents.  There are several functions to talk about and I realize this may make this idea fragmented, but they all have to deal with File I/O functions, that are native, but lack the features of the OpenG equivalent.


Generate Temporary File Path


Temporary File Path.png

Here we see the OpenG Temporary File Name allows for specifying the file name and extension.  So for instance my name can be "My Temp File %d.hoo".  I can also specify a subfolder to put things in, which makes cleanup easier because I can just delete the whole subfolder when I'm done.  This can make a files in "%temp%\Applicatoin Temp\My Temp File %d.hoo", but the native function can only speicfy a extension for the temporary file.


File Extensions


File Extension.png

Here we see the OpenG Strip Path Extension accepts a file and returns the root and extension.  Here the function is polymorphic and accepts a string, a path, an array of paths, or an array of strings.  This can be helpful if you have a file name and want to get the root and extension.  OpenG also has a Convert File Extension which can replace a file extension if one exists.  If one doesn't exist it adds one.  This also is polymorphic and accepts a string or a path again useful for a file name, or a relative and absolute path.


The native function only works on paths, and there is no convert function.


Build Strip Path


Build Strip Path.png

Here the OpenG functions are polymorphic.  The Build Path accepts a path as the base, or an array of paths.  The name or relative path can be a string, or an array of strings, or a path or an array of paths. And the Strip Path accepts a path, or an array of paths to strip.  This is 8 polymorphic types between the two functions, but the native functions combined only have 3.  The native Build Path accepts a string or path as the name or relative path, and strip path isn't polymorphic at all.


For existing functions I understand NI hasn't changed much but when NI introduced the Get File Extension, and Generate Temporary Path, I was confused why NI wouldn't try to duplicate the standard OpenG functions.  Sorta like how when NI made the Clear Errors accept an error to clear why they didn't implement the function similar to OpenG's filter errors which is polymorphic.

My particular use case involves TCP Connection RefNums and Queue Refnums, but this could be applied to ALL refnums, as well.


When passing a RefNum from one VI to another, I realize it's not useful to show the numeric value on the front panel connecting control/indicator.


However, what WOULD be useful is to indicate when it's a Not-A-Refnum. 


Perhaps a red dot, or a red background, would indicate that this Refnum is Not-A-Refnum, and absence of the dot, or a plain background would indicate the opposite.

As a new adopter of the Unit Tetst Framework I was keen to export my UTF Results from the Result dialogue for use in an external test report (Word document).

The Save button creates a datalog file only suitable for Loading back into the same dialogue. There's no immediately obvious way to export your results in a readable format.


After scrutiny and assistance I found that you can configure automatic creation of HTML, ATML and ASCII formatted reports by changing your Project settings. Hmm. Not quite what I want.


I want to be able to quickly and immediately export my UTF Results to Clipboard or File in my chosen format from the UTF Results dialogue please.



There are suggestions on the Idea Exchange to annotate subVI nodes with various attributes (this one, for example). I think that's a losing strategy. There just isn't space for all the annotations that might be of interest on a given node, and not all of the annotations make a difference to user's understanding of a given node. As an example, knowing that a subVI is reentrant is very important to understanding how a point-by-point read subVI works but unimportant to understanding how Trim Whitespace works. Also, not all of the annotations that we could imagine are simple "on or off" settings. A subVI that uses a local variable might be using it in an iterative algorithm or might be using it to store state between calls. If it is storing state, that might be something that a caller should know about.


These are the sorts of things that could be scanned for on a VI when LabVIEW launches the Icon Editor. If we had standard glyphs for interesting attributes of a VI, LabVIEW could have a section to recommend glyphs to add to the icon. This would not be an automated "always add this glyph" system that some people have requested because I do not think that we want the glyphs on every node just because it has the attribute. But some nodes it is worth calling out, and putting it in the Icon Editor would make it easy to add such glyphs. We might even have a fast "add recommended and arrange layers" button that spills all the glyphs onto the icon and then moves them around to minimize overlap, taking the existing layers into account.

Option to open VIs or projects for viewing only ("locked" or "read-only")

Status: New
by Active Participant SFK ‎04-22-2015 08:57 AM - edited ‎04-22-2015 09:06 AM

When reviewing old projects or VIs, the "VI changed" title bar star is always only a few mouse clicks away. And beware of accidentally opening an old project with a newer LabVIEW version!


You all know the "vi has unsaved changes" dialogs that follow when just wanting to close the windows, and who has not at least a dozen times saved an old VI in one of these situations just out of a misplaced click or the habit to save your code whenever you you are prompted to...



This is why I propose a new file menu entry: open (locked)... or open (read-only)... or an "open options" control in the file dialog.


Its functionality would be to open the selected file or project in a similar way like the locked VIs: you can look at them, browse through case or event structures, but cannot change a thing...


Even better would be the option to allow changes (e. g. move/delete some portions before selecting the rest for copy&paste), but to prevent re-saving the file under the same name. For this case, trying <CTRL-S> or closing the file would open a dialog stating that the VI was opened as "read-only" and that you may either discard the changes or save the file under a new name.


Of course, this "read-only" flag would be inherited to all subVIs, typedefs etcetera that would be opened from the original project or VI.


And to make my whishlist complete, a color coding of the VI window / project frames would signalize the read-only state of the code:



By the way: Wouldn't it be nice if VIs in vi.lib featured this opening mode by default?


Best regards,



Probe switcheroo

Status: New
by Knight of NI on ‎04-27-2015 04:52 PM

Sometimes I have several parallel array wires and I want to probe one of them with a graph probe. During debugging, I notice that I actually want to probe one of the other wires instead.


Current procedure:

Create an new probe on the other wire. If we do that many times, we will have so many probes as to make it difficult to keep track of them all.


Create a new probe on the other wire and delete the old probe. Several steps.


Wouldn't it be nice if we could Control-click on a probe number on the diagram, get the switcheroo cursor, and then click on a different wire of the same type to move the probe over. It would work very similar to how we currently are able to swap terminals on the connector.


Summary: Allow switcheroo on probes :smileyvery-happy:

Index & Bundle Cluster array should retain element names

Status: New
by Knight of NI ‎02-13-2015 11:31 AM - edited ‎02-13-2015 11:32 AM

(Inspired by this discussion)


The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).


The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.


Wire : Right Click --> Visbile --> Label  (Its void Now )


1.png                                  2.png


Solution : It can take the control Name as default label of the wire,  instead of  being Void





Not sure if this idea is already proposed. 



Cut and Paste between LabVIEW versions

Status: New
by Member jlokanis on ‎05-06-2015 06:04 PM

Allow BD code and FP objects to be copied to the clipboard from a VI in an older version of LabVIEW and then pasted into a VI in a newer version.  If the code is obsolete or contains depricated functions then it should be processed the same way a VI is when loaded into a newer version of LabVIEW.

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