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

The VISA test panel is a very valuable tool for troubleshooting instrument connectivity issues.


This used to be included with the VISA runtime, or at least with any installer that also included the VISA runtime.


Now I have to separately download and install the FULL VISA just to get this valuable tool. 


That makes installing a LabVIEW executable a multistep process as now I have to run two different installers. 


NI-MAX and the VISA test panel should ALWAYS BE included in any installer that includes the VISA runtime.

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

(In LV2017) "Browse Relationshiips\Unopened SubVIs" shows a list of icons with truncated VI names - about 12 characters per VI. When looking through a list of similar icons, one has to hover over each icon to see the full VI name.  This is impractical when hunting through tens or hundreds of SubVIs.  If unopened SubVIs could appear as an alphabetically-sorted list of VI names, it would be very helpful.






When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:




Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:




To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):




The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.




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 (Smiley Very 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. Smiley Very Happy

Okay so lets say you have a VI that you developed, and works great on its own.  You have some nice scaling and control manipulation with panes and custom resizing code.  All works great.  Then you realize this might be handy to have in a subpanel.  So you insert it into a subpanel, which itself can be resized at runtime.  The only problem is, if code isn't written to handle the resize of the Subpanel properly, then the user could accidentally make the subpanel smaller than the minimum VI size that is inserted into it.  At which point the UI will get messed up and making the subpanel larger will not bring it back to the desired look.  Here is a thread where I post a simple example.  If the subpanel is set to fit to a pane, then you could programatically set the minimum pane size, to be the same as the minimum front panel window size, of the VI being inserted.


But if the Subpanel isn't in a pane, then there could be other issues.  So this idea is to have a property of a Subpanel that is "Minimum Subpanel Size".  Which will not allow the control to be smaller than a set size.  To make things even easier I propose a property that is "Set Minimum Subpanel Size to Minimum Front Panel Size".  Now when you try to make the Subpanel too small with a property node, it will generate an error, just like if you try to set the Front Panel too small with a property node.  And if the Subpanel is in a pane and being resized, this would prevent the control from getting smaller, and prevent the pane from getting smaller.

Good day forum


Proposal: to have a option to check for properties that can behaviourally change during deployment.




Case: recently built a VI that is called from TestStand and encountered error during execution in the end-user PC (installed with TS and LV RTEs) and found this property that can behave differently in RTE environment. Retested in LabVIEW through application build but received no incompatibility or possible error notifications. Installer builds (with automatically select recommended installers checked) also did not indicate the necessity of having the Development System environment.


A optional check on this type of property could be nice.

Untitled 1.png


Thank you Smiley Happy


Maybe this has been already requested elsewhere and I'm missing it....

but it would be useful to have a Wait (ms) with connectors for error in and out.

This can help keeping the BD clean...



Here's how we currently make cluster element labels appear, and a proposed idea for improvement.


Good day forum


Proposal: add "retain value if unwired" option to shift registers. particularly useful to reduce wire clutter inside and outside of loops.LIX.png

Have a great day



As discussed here, please incorporate the System Controls 2.0 UI elements into core LabVIEW. This would eliminate the need to visit VIPM to obtain the full functionality of the System UI control palette. System Controls 2.0 is not an additional UI style, rather it is the partial completion of the original System controls palette.


Including these controls in the default installation would allow the merging of these two palette entries for those that use the System controls for UI development.








Motivation: in my recent project I have got a request from the end user that it would be nice to store configuration data in the same TDMS file where we store measurement results. Of course, we can create this feature programmatically, like we parse through the typdef cluster, using label names and different data types, we can create a kind of API for a TDMS Cluster read/write. However, it is difficult to make it generic, and this is an extra work anyway.

So it would be nice to save my complex Typdef cluster into TDMS, where I store measurement results in a user readable manner (via the Excel plugin) inside different groups and channels. The stored configuration cluster does NOT need to be user readable!

Since TDMS does not have this feature, as a dirty and simple workaround, I will always produce two files during measurement/data processing sequences: a TDMS, and an INI file (via the OpenG Write INI Cluster), then programmatically ZIP them into a single file for data backup (for future reference, it is safer this way).


Would not be nice if we could just write a Typdef cluster to and read from a TDMS file directly?

Like what we can do with the OpenG Read/Write INI Cluster VIs. I understand there is a strong reason why TDMS files limit the data types we can write to them, and it is not allowed to use undefined data sizes, like Variants, strings. Well, we can write strings to TDMS files, but there are some issues/difficulties with this approach if we want to go through a Typedef Cluster->String->TDMS file storing route. Hoovahh had a post about these challenges 2 years ago, where he mentioned he might make it into an Idea, but I could not find it in this forum board, so I make it an Idea: 


I imagine, NI could implement such feature into TDMS in a similar way, like there would be an "internal part" of the TDMS file where the Cluster is stored as a Variant in binary format. I do not know how the internal things work in a TDMS file, but I imagine such new feature implemented as an extra data type for the TDMS Set Properties would not hurt the speed performance of the Group/Channel level things...?

To support modern web thin clients, the LabVIEW webservice needs to support the OPTIONS request. When a web browser makes a cross origin request there are a few rules that the response must comply with before the browser will provide with the result to the web application. The OPTIONS request is needed to respond to these requests.


A cross origin request is any request where an application running on one domain needs to make a request to another domain. For example, if there was a javascript application running on the domain and it needed to make a AJAX request to, the browser considers this a cross origin request. This is a common setup when the thin client is being hosted by one server, and the webservice is being hosted by another server.


Depending on the request, the browser may issue a "preflight" request. "Standard" requests are GET and POST requests without custom header fields only require the response has an additional headers. Other requests (PUT, DELETE, GET w/ headers, POST w/ headers) require a preflight request. A preflight request is an OPTIONS request. If the OPTIONS request doesn't get an appropriate response, the browser will not even make the actual request.


For example, I'm starting an application and here's how I'd like it setup.


1. Windows PC. This is the central server for the application. There will be a normal LabVIEW application running on this computer. There will also be a web service run on this computer. The web service will mainly host a web application written using HTML/CSS/Javascript (although it could be written using HTML vis from NXG).


2. A bunch of CRIOs. These CRIOs will also host their own web service to get system information, measurements, and diagnostics. As new CRIOs are commissioned, they'll report to the Windows PC.


Now a user uses their web browser to access to the windows PC. The Javascript Application (which is hosted on the Windows web service) provides the user with a list of all commissioned CRIOs. They then click on one and the javascript application starts to make requests directly to the CRIO's web service. Since these CRIO's are on a separate IP address, the browser flags this as a CORS request. This means that an OPTIONS request can be sent. Since I can't handle an OPTIONS request in a LabVIEW web service, I can't implement this.


This is just one example. Another case would be an Apache hosted web application hosted on an Amazon EC2 needs to make requests to a LabVIEW web service running in a different domain. Basically any time a web application (AKA something running in the browser) needs to communicate with a LabVIEW web service you'll run into this problem.

Take for example an enum that is saved as a type def. The enum has many items (let's say words) of varying length.


In order to see all of the elements, inclusive of the widest one, the array can be sized with the right-click option "Size to Widest Element".


If the type def'd enum is edited, and a longer element is added, the array of enum constants will not size to the widest element. This can be frustrating, as dozens (or more) of these arrays scattered about the program are rendered unreadable.


If the user has previously chosen to "Size to Widest Element", this setting should persist. If the user edits the enum, all of the array constants should size to the widest element.


-------------------------- Example ----------------------------------------------------------------------

 size to widest.pngsize to widest2.png





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.



It's a common convention that the space bar is used to pause/un-pause videos that are playing. It would make sense to me that pressing the space key would toggle the pause button (Pause / Continue).


1) Pressing Space Bar key would be the same as pressing "Pause" on the VI toolbar.




2) Pressing Space Bar key again would "Continue" (un-pause).



Many Real-Time Testing (RTT) systems require a mechanism to store data in one central location that can be accessed by the different parts of the application. The Buffered Variable Table (BVT) is a set of LabVIEW VIs that developers use to store and retrieve data asynchronously from different parts of an application.


Normally, when I program applications in RTT, I need store data in one central location that can be accessed by the different parts of the application, for this, I usually use "queue operations" with a fixed size.


But sometimes, I need to insert an element at the beginning of the queue, but if it is full, it is necessary to dequeue and queue again.


To solve this problem, I could use a code similar to the image, but the applications could become unstable.



For this reason, my proposal is that labview provides the function of "Lossy Enqueue Element At Opposite End".