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


I just had a call with a customer that have a problem: 

we cannot install multiple version of drivers to develop applications with different driver versions. 

This problem happens to our partners.



I have a customer that want to uses LabVIEW 2014 and another one that uses LabVIEW 2017. So I would like to make a project with 2014's dependencies and another project with 2017's dependencies. 


So the idea is to manage the dependencies in the project itself.


Best regards, 


So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1.  This means the function will wait forever until an event comes in.  But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.


This idea is to have similar functionality when it comes to user events.  I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it.  If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running.  In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.


What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.






I've got some calls to low level VIs that rely on windows system dlls within a larger top level VI. To make that application work on Windows and Linux, I've put conditional disable structures around the dll calls. When I open the top level VI in Linux, I have to click through a bunch of "Find missing file" dialogs for the Windows system dlls. If I cancel through all the dialogs, the VI still compiles and runs correctly in Linux, so the Conditional Disable structures are doing most of what they should, but the dialogs are annoying and can cause problems with automated builds and other hands-off activities. Since the code is inside a conditional disable structure, it seems to me that LabVIEW has all the information in needs to know it shouldn't load that stuff, so it would be great to get rid of these nuisance dialogs.





                        NI does not need to worry about the code, I provide it, it's a proposal plug&play  Smiley Happy






Instead of right click on the Array to Cluster for Cluster Size, double click will be ease for the programmer to select the size of cluster


Double click should enable this pop up.


A right click option for each auto indexed array that allows will not use the length of that array in choosing the number of iterations. If there is no input to the count terminal all auto-indexed terminals can go beyond their length otherwise at least one must remain as a driver for determining the length. If multiple are left with the default (existing) behavior, the shortest length will be used. For any iteration where the array is shorter that the "i" of the loop, the defaults for the data type will be returned (just as if "index array" blocks had been used inside the loop. 


Similarly the loop could be set to use the longest array instead of the shortest.


Additionally a similar function could be done when any array compare or math functions are done. In the case of compare functions if set to use longest array, the result will be false for any compare to an empty element of the shorter array, and math functions will use the default data type for empty elements.

This idea came to me from Darren's Nugget 2-23-2018 on Data Agnostic Probes I thought it might be useful to write a Probe.vim or specifically, a data type malleable probe to gain the ability to have some access to the data itself in a general smart probe and maintain the ability to display the data in a type specific manner.


One example would be a "Data History Probe" that displays the history values of any data type.  I'm sure there are other good uses.

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.

One of the fiddly things I seem to do more than I'd like is adjust the bottom of block diagram comments to the right height. At a minimum there, but also for similar text boxes on the front panel or subdiagram labels, etc. I'd like to have a snap feature that sizes to a multiple of the text height. Examples:


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



I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 


Sometimes when passing multiple values into "format into string" to build a complicated string e.g. a chain of commands for a device, it is possible that the format specifiers may become hard to notice if they aren't all aligned in the same column. I would like to propse that when a string constant is wired to the string formatter terminal of  "format into string", the format specifiers be emboldened.

For example:

SOURCE:ARB:srate %.2f


When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.

Title says all. Can't believe it was never proposed; if it was, I couldn't find.

Missing that, I have to that programmatically, but it's always a detour:


Should be quite easy to change the property page like e.g:


(6 colors for system booleans, 4 for all others, as known)



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.

Single control items have "NewVal" and "OldVal" in the Data Node for Value Change events. This is applies for numeric, boolean, and strings. It would be nice if this feature were included for listbox and multicolumn listbox labels for the "Edit Cell" events.

Use case: I use a listbox to show the materials for which the user has defined experiment settings for. These settings are saved in an XML file with the material name as an attribute. In the event that the user wants to edit the name in the listbox, it would be nice if they could just do that directly in the list box and the XML change will be handled automatically in the background. Currently to find the right element in the XML, I use an XPath to search for the label selected from the listbox. If the user edits the name, I need to know the old value in order to replace the existing name. Presently, this does not work as the Event Data Node only supplies me with the new value.

It would be useful to insert a VI directly from a project or from a class into a line.


When setting up In Place Element structures, the current work flow is:


  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.