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!
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 am not happy when I inherit legacy code where VIs have inconsistent alignment grid options, as shown in the image below.Inconsistent Alignment Grids.jpg


My team has coding standards we follow, and those standards include alignment grid options. It is labor-intensive to change alignment grid options on legacy VIs because you have to do it by hand, and clicks quickly add up. I wish I could automate such changes.


I’d like to see a few new properties to expose settings available in the editor, as shown below.Alignment Grid Property Nodes.jpg

These properties need to support both read and write.

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.

With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.


For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.


For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.




Not a duplicate of


[admin edit: Adding animation image at the request of the OP]


Another for the wish list.


It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).


The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.


See attached pic for an mock up.

case glyphs.PNG

 There are probably lots of menus that could benefit from something like this.



Suppose that we want to start coding my Real-Time application, but the hardware hasn't arrived yet.


We can't Discover the chassis + modules, so we need to add modules manually.



Current editor



To add N modules, we need to launch this dialog N times:


  1. Right-click on Chassis in the Project Explorer
  2. Hover over "New"
  3. Click "C Series Modules…"
  4. Click "New target or device"
  5. Click "C Series Module"
  6. Click "OK"
  7. Wait for LabVIEW to fetch module list (wait ~1 second)
  8. Select Type (2 clicks)
  9. Select Location (2 clicks)
  10. Click "OK"
  11. Go to #1 to add a new module


How tedious!



Proposed Editor

Wouldn't it be nice if we could set up all the modules in 1 dialog?





  • Table auto-fills itself with modules already in the project
  • Number of rows is determined by the chassis model. No need to select Location
  • Ability to leave rows/slots empty
  • Editable Name field (with default name) appears upon selecting Type
  • Description appears upon selecting Type



Feel the difference

Adding N modules (using default names) requires...

  • Current dialog: 10N clicks, N hovers, waiting N seconds
  • Proposed dialog*: (6+2N) clicks, 1 hover, waiting 1 second


So, adding 8 modules requires...

  • Current dialog: 80 clicks, 8 hovers, waiting 8 seconds
  • Proposed dialog*: 22 clicks, 1 hover, waiting 1 second

*Assuming that steps 1-7 and 10 need to be performed once


A pretty common use case of LVCompare in my workflow is to use it as a diff tool in SVN to compare different versions of a VI. When I do that, the previous version is downloaded into a temp directory, and then there is a decent amount of load time because dependency paths have to be resolved differently for the version in the temp directory and some recompiling happens. For top-level VIs in large applications, it seems like the whole dependency tree is getting loaded, which takes a long time. But really, for comparing VIs, there's no need to load the contents of lower level subVIs (and their dependencies, and dependencies of dependencies, etc.) As long as the connector pane, typedefs on the connector pane, and the icon of a subVI are loaded, that should be enough information for a visual diff of the top level VI.

Remote front panels are easy to get working and do a great job of viewing and controlling front panels for existing LabVIEW programs. It is not the best approach for providing LabVIEW functionality in a web page, but can be up and running quickly. The problem is that there is very little security built into the LabVIEW Web Server. Years ago, when it was using the G Web Server, you could use simple HTTP authentication via htaccess.txt files. That feature is no longer supported. You can embed the control in a web page hosted by another web server and have the control point to the LabVIEW web server. This provides an outer shell of authentication and security, but still exposes the vulnerable LabVIEW Web Server to potentially malicious actors. The existing locks on IP address do nothing to protect against other users behind the same firewall.


So, my request is to simply provide better security and authentication features for the LabVIEW Web Server that is serving up remote front panels. Just re-implementing basic HTTP authentication and restricting access to folders via htaccess would go a long way with (I presume) not much effort. NI could even switch to an open source web server with existing authentication capabilities and customize it to serve front panels. Or provide a custom module/handler/action for Apache (or similar for IIS) to serve front panels.


For a feature that has been around for so long, I am surprised that security and authentication functionality has not been improved or updated.

During LabVIEW Development was a PXI Real-Time System connected (LAN) next to my Laptop and process Build/Deployment was no problem.

Now the RT has been shipped far away to customer site and i have no longer access to that network.


So I need an other way to distribute and

here is my IDEA #1:  (below is another IDEA #2)


Offline RT-Distribution LabVIEW Idea Exchange.GIF


FACT : Most of all customers have no knowledge about "How to find the Real-Time System and update the Application on it".


So the new item will built an "Offline Installer.exe" and will run on any customer PC to a full automated update job automatically.



 - create a detailed installation report which can be stored and send back to the developer.

 - In case of the Real-Time System isn't connected to any LAN, the customer could use the "Offline Installer.exe" to prepare an USB-Stick which has to be plugged into the Real-Time System. Then a reboot will launch the full automated application update process. (the "RT LEDs" will give feedback when the process is finished)    




I tried also another way but without success:


Step 1: Add a ZIP File into the Project Explorer : "My Zip File"

Offline RT-Distribution 1.GIF


Step 2 : Configure the "My Zip File" => Add "My Real-Time Application" 

Offline RT-Distribution 2 zip.GIF


Step 3 : Build "My Zip File"...but the Result was bad :

Offline RT-Distribution 2 Build My Zip File.GIF


But anyway, if the would be successful there are a lot of more steps needed:

 - sending the ZIP to the customer

 - unpack ZIP

 - find Real-Time System at customers network

 - a FTP tool is needed to update the system.

 - There is no way to stop the running Application (from a PC without NI-Software)



The update with "ZIP" is far away from a comfortable solution. 




If the Real-Time System has a running webserver (the thing which is using Silverlight),

then the application could be updated by using a webbrowser.

So, first we have to update the webserver on the Real-Time System (as difficult as updating the application)


(But who the f..k has Silverlight installed  )



I would love to be able to show a ruler on the front panel....when turned on it should float above the objects on the panel...not unlike a cursor with lines in both planes if the panel was a graph. Unlike the grid this would make it simple to align e.g. columns when you have multiple tables underneath eachother. You could of course have this on the diagram as well, but the main use for such accuracy is on the front panel.


There are thirds party tools that do this, but it seems more natural to have it available in LV when we already have a grid that only solves a part of the alignment challenge.