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

Pretty simple idea.  When you are creating installers, you are allowed to install files in many different locations.  Including lots of system locations.


But for some reason, Public Documents is not one of these destinations.  It should be.


Because its not in the list, I need to go through some annoying workarounds which I don't totally trust.



It would open a copy of the project that has been copied to a user selected directory along with all its dependencies. 


The same thing can be accomplished by immediately doing a Save As>>Duplicate .lvproj>Include All Dependencies. But I have on several occasions "checked something really quick" only to come back to a modified example I didn't realize I modified.


In addition to making this very common copy operation simpler, it would be a nod to new labview users that they need to create copies of examples before modifying them.





Timestamp Conversion Primitive

Status: New
by Trusted Enthusiast on ‎04-16-2014 07:42 AM

There are a plethora of timestamp formats used by various operating systems and applications. The 1588 internet time protocol itself lists several. Windows is different from various flavors of Linux, and Excel is very different from about all of them. Then there are the details of daylight savings time, leap years, etc. LabVIEW contains all the tools to convert from one of these formats to another, but getting it right can be difficult. I propose a simple primitive to do this conversion. It would need to be polymorphic to handle the different data types that timestamps can take. This should only handle numeric data types, such as the numeric Excel timestamp (a double) or a Linux timestamp (an integer). Text-based timestamps are already handled fairly well. Inputs would be timestamp, input format type, output format type, and error. Outputs would be resultant format and error.


Include 'Transpose Array' method in the shortcut menu of a 2D array constant/control/indicator

Status: New
by Active Participant moderator1983 on ‎04-15-2014 04:56 AM - last edited on ‎04-15-2014 10:33 AM by Trusted Enthusiast

Similar to 'Insert' and 'Delete' methods, please include 'Transpose Array' method as shown below:


Method to transpose the array



The In Place Element (IPE) is great and so are Data Value References (DVRs).... but... well sometimes I'm not such a great programmer and I will cause a dead lock in my code causing what looks like a "hang". Debugging can be hard in that case when trying to figure out which vi was trying to access the DVR. Also if I'm using the dvr for some sort of global storage, i may want an error to ocurr if some piece of code holds onto the DVR lock for too long. 


I'd love for the IPE to have a timeout when you have 1 or more DVRs and if ALL of the references are not available in the specified time, the structure returns an error. 

On downloading a file from internet and if the file already exists (file with the same name), it automatically appends an auto-incrementing number to the file name, wouldn't be it nice to have the similar feature (may be optional) with Open/Create/Replace File Function.


Append with auto incrementing number in the file name



Consider the scenario, you've enabled this option ('append number if file already exists' as shown in above figure) while using Open/Create/Replace File Function and operation input is 'create' and name of the file is MyFile.txt, which already exists then this fuction should create a new file with name MyFile (1).txt (or may be MyFile (2).txt if MyFile (1).txt also exists and so on).


Wires should inherit their name from their source

Status: New
by Active Participant X. on ‎04-11-2014 12:31 PM - last edited on ‎04-15-2014 05:54 PM by Active Participant JordanG

Right now, if you select to show the label of a wire connected to the output of a named cluster, the label is empty:




The white space surrounded by a box pointed to by the line is the location of the blinking cursor.

This is similar for all wire sources: controls, constants, function outputs, etc and should behave similarly for all.


Expression Node Redesign

Status: New
by Knight of NI ‎04-05-2014 01:05 PM - edited ‎04-05-2014 01:14 PM

For reasons outlined in detail in this idea, the the expression node should be redesigned. These vertical lines are too thick and the end arrows are pointless and too busy.


After all, the expression node is basically a [single line|single variable] formula node and for this reason it should look more similar to a formula node.


Here is my suggestion for the redesigned expression node (on the right). The current design is shown on the left for comparison.




Note that the grey left and right borders are exactly matched to the border design of the formula node, making things consistent and intuitive. (Top and bottom should remain single pixel to save diagram space). 



Connector Pane Context Menu Find Terminal

Status: New
by Member rnigro on ‎04-09-2014 08:44 AM


Right-Clicking on a connector in the connector pane brings up a context menu.  This menu should have the same "Find Terminal" option as if you click on the FP object.  This will provide quick access to the Terminal especially if the FP object is hidden.


 Connector Pane Find Terminal.png

When I duplicate a VI inside a library or class using Save As... and check the option to add the duplicated VI to the class/library I would like the new VI to be placed in the same virtual folder as the original.  I will settle for what I asked for in the title, an additional option to perform the same.



This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.


To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.


Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.


My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.


Typical phone exchange yesterday:


me: "just click my installer and install the program"

him: "OK, done."

me: "now run it."

him: "OK, ...... error about 2013 run-time engine".

me: "OK, install the run-time engine using the link I sent you in the same e-mail".

him: "clicking the link to go to the run time engine page....

        (..30 second discussion to decide between downloader and direct download...)"

him: "click..(wait for it!)... .it wants me to register..."

me: "OK, let's forget about that. come down to the lab and I will do it for you."


End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.


While gazillions (:smileyvery-happy:) of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.


I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to "[] I don't want to register at this time, just download the run-time!".



Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers. :smileyvery-happy:


Connector pane double click terminal jumps to control

Status: New
by Member matt.baker ‎03-26-2014 05:16 AM - edited ‎03-26-2014 05:19 AM

Suggestion: Double clicking a connected terminal on the connector pane highlights and jumps to the connected control. This would be useful for controls that are off screen or hidden.


Similar behavior to double clicking the associated terminal/icon on the block diagram, where it automatically repositions the front panel's view.




Make the "Expression Node" and "Convert Unit" visually distinct

Status: New
by Knight of NI ‎04-03-2014 04:17 PM - edited ‎04-03-2014 04:26 PM

As outlined in this post, the current identical look of the Expression Node and Convert Unit can cause serious miscommunications, since their functions are completely different.


I suggest that they are made to look different so we can tell immediately what we have.


For example the two results below are very different, even though the code looks absolutely identical if the labels are hidden.


One possibility would be to make "convert unit" a different default background color (example shown below), but there are probably even better suggestions. How about rounded corners (not shown)?





Status: New
by Proven Zealot on ‎03-06-2014 03:46 PM

Yup,  Upgrading LabVIEW versions takes a day.


The "Process" today is:

  • Install from media
  • Configure the new LabVIEW.ini
  • install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
  • Mass Compile all them......
  • Fix palatte views... and import and mass compile User.lib\ for here.....
  • Sync glyphs on the icon editor (If the link works......)
  • Add VIT's
  • Add Project Templates
  • Mass compileVIt's and Templates
  • fix "Metadata.xml"...



Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

I thought this feature existed and this led to this aborted bug report.





Oftentime, I find myself needing to create a control (or an indicator) on a subVI so that I can connect a block diagram object to the subVI.

The object can be a constant, a local or global variable, or of course a terminal.

Right now, selecting and copying the BD object and going to the subVI's FP and trying to paste the object results in nothing, unless it is a constant.

You have to go into the subVI's BD, paste the object (which, if you have selected a local variable, will become a terminal), double-click the terminal to switch to the FP and then manipulate this control/indicator (in my case, connect to the connector pane):


Step 1: Source BD


ScreenHunter_002.jpg <---- select the terminal and copy it


Step 2: Target FP


ScreenHunter_003.jpg<---------Oops, that's right, nothing happens if I try to paste it directly on the FP...


Step 3: Target BD


ScreenHunter_004.jpg<----- The terminal is pasted fine on the BD, but that's not where I want to work


Step 4: Go and find the Control on the FP and bring it back where you really want it!


The problem with that  approach is that LabVIEW is none too clever in terms of placing a FP object created from the BD.

If your subVI happens to be a carefully layed out UI, the new control might be dropped outside the visible area, and double-clicking the terminal to get to the control/indicator will move the visible part of the FP in order for the control to be visible.


It would be preferable to drop the newly created control precisely where you want it to be, hence the idea to bypass the BD altogether.

Current behavior:
When configuring a type specifier for Open VI Reference so I can run Start Asynchronous Call, I drag a VI onto a type specifier VI Refnum.
If the pinout of that VI changes at all - even if the only change is to add an item to an enum - the call to Start Asynchronous Call breaks, because the types no longer match.


Desired behavior:
When configuring a type specifier (constant, control or indicator), I can maintain the link to the source VI, so if the pinout of that VI changes in any way, the type specifier doesn't have to be manually modified. In essence, I want an "Auto-update from type definition" option for type specifiers, with the VI as the type definition.

Currently, the VariantDataType  are buried deep in VI lib but they are very useful when trying to program based on datatype. Can we bring some of those functions into the light?


Get items from enum


Make express VIs closeable with the [X] in the upper right

Status: New
by Knight of NI on ‎03-25-2014 01:20 PM - last edited on ‎03-31-2014 01:19 PM by Active Participant JordanG

The configuration panel of express VIs has the [X] disabled in the upper right, but contains standard [OK], [Cancel] and [help] buttons.


Every computer users is familiar with the function of the window close button [X], and for convenience it should be enabled unless there is a very good reason to disable it. Such a reason does not exist for express VI panels. Pressing the [X] should act indentically to pressing the [Cancel] button. Note that even the <esc> key is already bound to the cancel button as it should!


So why is [X] disabled? This is unecessary micromanagement of the user! Do it like this, not like that!!! (slap on the hand!)


Users should have all intuitive and typical methods available to cancel out of an express dialog:


  • [X] (currenty not allowed for no good reason at all!)
  • [Cancel]  (already mplemented!)
  • pressing <esc> (already implemented!)


Idea summary:

The configuration panel of express VIs should have the windows "close" button ([X] in the upper right) enabled and when pressed, it should act identically to the [Cancel] button on the panel.






Functional "Open With" from Explorer

Status: New
by Member mikpal on ‎02-26-2014 09:06 AM

If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.


Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.




The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.



Show Reentrancy in Context Help

Status: New
by Active Participant Mr._Jim on ‎01-31-2014 08:43 AM

Hi all,


What I'm asking for is an optional indication of reentrancy in the context help window.





This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.



I realize that Greg Freeman suggested something similar.  My intent here is to narrow down several ideas from that conversation down to a single suggestion.

(I hope I still didn't manage to post a duplicate. Apologies if I did.)





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