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

Windows 10 now handles long file paths although it has to be enabled with via various possible registry or group policy edits. Windows applications have to opt in. LabVIEW source code should be able to utilize long file paths.

On a For Loop that is configured to have parallel iterations there is a nifty feature when using errors on a shift register.  This feature is explained in an article here.  It basically ensures that For Loops that run 0 times, will preserve the incoming error as if the tunnel was a shift register.  However this feature also means that errors from iteration 0, won't be passed into iteration 1.  What is returned if the loop runs 0 times is just the incoming error.  But if it runs for more than that, the errors are all merged and returned will be the first error seen.



This idea is just to allow this already existing feature to work on non-parallel configured For Loops.  When would this be useful?  Say I want to delete an array of files.  I want to attempt to delete all files, even if there is an error in trying to delete some, just keep trying to delete the other files.  Initially you may think this:



But that has the clear problem that if the incoming array is empty, then the error will be cleared.  So we often do something like this.


And honestly this bit of code isn't that big of a deal, but this feature already exists.  However it only works on For Loops that are configured to run iterations in parallel.  In this case I might be attempting to delete files in a specific order due to their placement on disk, and running in parallel isn't what I want.


Since not everyone wants all errors in loops to act this way it would need to be a right click menu to turn the tunnel into a normal one, a shift registered one, or a preserve and merge one.


That is what I want.

Currently, DETT looks like this:


But it should look like a proper profiler allowing for exploring and easily visualizing performance, threads, call stacks and memory usage at a glance (similar to this):





NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?


  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

So I'm going through a bunch of VIs and relinking them.  So I go to a folder and select say 100 VIs and drop them into a new blank VI.  A bunch of dialogs come up telling me VIs are missing and I ignore them all at the moment.  Then I go to the block diagram to find which ones are broken to review them one at a time.  The only problem is the error list window displays over 100 errors that aren't "SubVI is not Executable".  I have all kinds of errors about required inputs not being wired, and for "This VI cannot access the referenced item in private scope".  Well I don't really care I'm not trying to run these I'm just trying to find all broken VIs and fix them.


Which got me thinking, can we have a category view of some kind in the Error List Window?


Required input not wired.pngSubVI not executable.png

Under Web Services there is a conversion palette.  One of the functions here is to convert LV Image data to a PNG stream.  This is super useful when dealing with sending and receiving large amounts of PNG data over something like websockets.  I've used this in places where a web page can control a VI, and the image of some front panel controls can be sent to the web page.


However only recently did I realize this function turns the image into a PNG stream that is completely uncompressed.  This idea is to expose the Compression input to the VI.  Here is just one example where I get the image of a control then represent it as a PNG.  With no compression this file is over 64KB.  With just the most minimum compression that drops to 3KB, and down to 2KB under the highest compression.



The recently introduced Raspberry Pi is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).


The Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 15 times the processing power!


Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?

If I have an existing cluster in my project and one day I decide to delete one of the elements of that cluster, LabVIEW tries to fix all the references or black them out to help me find the errors.  However, It seems that LabVIEW in some instances keeps track of clusters internal controls with an index and when you delete something, those indexes are now messed up. 


For Example, if you have a property node linked directly to an item within that cluster, then you delete an item in that cluster, the property node now points to something else.  OOOPS! 


Also, if you have an Event Structure Case pointed to a control within this cluster, and one of the other controls in the cluster get's deleted, this Event structure case now points to the wrong thing!


LabVIEW is internally keeping track of the controls in a cluster with an index.  It works fine as long as you only add new stuff to the cluster.  But if you delete things, LabVIEW does not handle it well.

If LabVIEW instead had a notion of the name of the items, then it probably could recover well when an item was deleted from a cluster.

We could add a way, for example a parameter key in INI file of LabVIEW.exe, in order to run LabVIEW.exe silently, so without the splash screen and the getting started window, like a background process.


Example use case:

When you execute a build specification thanks to LabVIEWCLI (operation name: ExecuteBuildSpec,, it runs LabVIEW.exe to complete the request. LabVIEW.exe is opened with the splashcreen and the main window. It's terrible, I want to use LabVIEWCLI to do some operation programmatically and silently (background mode) from my code/app.


The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.



For community solution and examples of these features please go to ->


This could include also Pretty JSON since XML and JSON are interchangeable ->


Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.


Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:




AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!


We need this:


 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.


 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

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.






Using the application builder is problematic if the destination folder is monitored by syncing tools such as Google Drive (Backup&Sync), Onedrive, etc.


During building, there are tons of file operations in rapid sequence, potentially crashing the sync tools or causing false file conflicts (recent example).


To avoid these issues, I wonder if the building steps could be forced to take place in the temporary folder, followed by a final clean move to the destination. My guess this would make building more stable and compatible with external folder syncing tools.


It would be nice if the LabVIEW primitives for TCP allowed for the creation of a socket without actually connecting it to an endpoint.  My thoughts are that there would be two new commands added to the TCP palette:


TCP Create Connection (Advanced)

TCP Open Connection (Advanced)


TCP Create Connection (Advanced) would create the socket but not perform the connect() method on that socket.  I would imagine that it would otherwise look and feel quite like the current TCP Open Connection, except that the user would need to manually run TCP Open Connection (Advanced) afterwards that would perform the connect() method on that socket.


I have a need to access the raw socket object before it is connected, using the TCP Get Raw Net in the vi.lib\Utility\tcp.llb library.  This VI works to get the handle that can be used by winsock and other Windows DLLs, however, it only allows for setting properties for a socket that is already connected.


Specifically I have a need to enable Windows FastPath for TCP to optimize the rate at which I can stream data between two applications.  Per the specification, this option must be enabled BEFORE the socket is connected.  Right now I can set this for the listener on the server side (TCP Create Listener creates a socket but does not connect), but I cannot set it for the TCP connection on the client side as the first method it calls is TCP Open Connection which returns a socket that is already connected.

A graphical programming language deserves to have great graphical tools representing the design of big applications.


It is possible to use scripting to understand if a method of a class has another class as input or output terminal and to know if a class composes another class in private data. The only thing I cannot do right now myself is to show this information in Class Hierarchy window. Representing the usage and composition relationships only requires parsing through the project once, and then every time it changes. 

I am right now using a script to parse through all project classes to understand which have what relationships, which are actors and which are messages and I draw a Plant UML diagram from that. The intermediate step is to generate Plant UML text, but this should be integrated into LV.





Please improve the readability of object oriented project with additional tools for LabVIEW. This is especially critical for NXG, where the currently the ability to understand an OO project is even more limited than LV19.

There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂





I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire.  I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal.  I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:


1.  Wire this specific VIM on error wires most often

2.  Likely don't want the VI to stall in the event of an error

3.  Would prefer to see that error propagated as quickly as possible like most other VIs do



As soon as we have more complicated data structures (e.g. clusters of arrays), a large portion of the FP real estate is wasted taken up by borders, frames and trims, etc.


We need a palette full of "Amish" 😉 controls, indicators, and containers that eliminate all that extra baggage. We have a few controls already in the classic palette, but this needs to be expanded to include all types of controls, including graphs, containers, etc.


A flat control consists of a plain square and some text (numerical value, string, ring, boolean text, etc). A flat container is a simple borderless container.  A flat graph is a simple line drawing that would look great on a b&w printer. A flat picture ring looks like the image alone.


They have a single area color and a single pixel outline, if both have the same color, the outline does not show. They can also be made transparent, of course. If we look at them in the control editor, there are only very few parts.


Now, why would that be useful?


Let's have a look a the data structure in the image. There is way too much fluff, distracting from the actual data. If we had flat objects, the same could look as the "table" below. Note that this is now the actual array of clusters, no formatting involved! It is fully operational, e.g. I can pick another enum value, uncheck the boolean, or enter data as in the cluster above.


Many years ago in LabVIEW 4, I actually made a borderless cluster container in the control editor and it looked fine, but it was difficult to use because it was nearly impossible the grab the right thing with the mouse at edit time.


The main problem of cours is that the object edges completely overlap, making targeted seletion with the mouse impossible. (For example the upper right corner pixel is the corner of an array, a cluster, another array, and an element at the same time.)


So what we need is a layer selection tool that allows us to pick what we want (similar to tools in graphics editing software). It could look similar to the context help shown in the picture with selection boxes for each line. Picking an object would show the relevant handles so we can intereact with the desired object. Another possibility would be to hover over the corner and hit a certain key to rotate trough all near elements until the right element is selected, showing it's resize handles. I am sure there are other solutions.


As a welcome side effect, redrawing such a FP is relatively cheap.


Message Edited by altenbach on 06-03-2009 09:20 AM
Message Edited by altenbach on 06-03-2009 09:20 AM



As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.

So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.

So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.Wire cleanup.PNG

I often run into the issue that I have one event case that I need to execute for multiple controls. Most of the times I simply read out the terminals and most of times I get the "NewVal" from the terminal. Some times however that's not the case. I'm currently having the issue that I use a property node of a control to trigger the event and every other time the terminal gives out the "OldVal".


I believe the proper way to solve this issue would be to go by the reference. I find this blows up the code more than it should do. Looking around in the community I've found two other ideas suggesting different solutions for this issue:


The first has multiple boolean controls triggering the same event. SectorEffector's solution was asking for a reference case structure, which might be a great idea, especially when the event is triggered by different data types. When I have multiple boolean triggering one event I almost always build an array from the terminals and convert the array to an integer, so that a case structure or other code can deal with the value. But again I'd have to deal with fiddling the new value from the triggering control and the other control values together.


The second mentions actually two ideas. The actual idea of rcpacini is to have an enum indicating which control triggered the event. This is a similar approach to what SectorEffector suggested. They're both aiming at using a case structure with a different cases for each event source. The alternative idea of rcpacini was to have event data elements for each control. The is more similar to my idea, but I would like to have the values of all registered event sources clustered together.


Here a side by side of the current solution and what I'd suggest:

New value by referenceNew value by referenceNew value clusterNew value cluster


The order of the events would determine the order of the values in the cluster, so a way to arrange the events like a move up and move down button would be helpful:

Event source order up/down buttonsEvent source order up/down buttons