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: 
Post an idea


The idea is to implement an option to choose for which RunTime-Version you want to compile your executable.

With this you could always use the newest LabVIEW development version but do not need to update all systems with a RunTime-Version.




When changing from LabVIEW 2019 to LabVIEW 2020, you need to update every RunTime-System also to version 2020.

This is difficult, if you have many worldwide runtime systems with different projects, where you can not easily update a RunTime-Version because of technical restrictions in production or access to the system.


This results in parallel use of different LabVIEW development versions for all of your projects.

Means a mess because once open a project in the wrong/newer LV-Version you have to store all changes "for older LV-Version" to continue work in right version.

Or, to avoid this, not upgrading to a newer LabVIEW development version and still working for example with LV16 in all projects.



Best way would be if you can update all projects to LV20 development system, but still be able to directly built executables for older runtimes.

When concatenating arrays, a wired empty 1D array, concatenated to an Empty 2D array will result in array index (1,0) and when this is concatenated to a populated 2D array, a top row is added with empty elements. This is in many cases unwanted behavior.


The suggest that LabVIEW includes a menu to configure the concatenate array node to ignore acting on any empty array(s) wired to that node.


Suggested New Menu Item for Concatenate Array.png


Because in some cases the resulting array will end up with an added top row with empty elements.


2D and 1D Empty Arrays yields Extra dimension.png


Anthony Lukindo

The code below will execute without error or warning. The value returned will be 127 in this case.


Why is that? I understand the error 91 is returned if the typedefs are incompatible but if the type is different but compatible I would expect a warning maybe?






Sometimes, it would be useful to view string constants as icons to save space on the block diagram.


1_String Constant Right Click.png


2_String Constant Details.png


I know that many extract wires 'upwards' and later on merge errors to collect errors and continue. From a layout perspective it's natural to add the top code to the top input of Merge Errors, but from a data flow perspective any error that happens there is often secondary to the 'base/lower' part of the code. This means you need to connect the top code to the bottom input of Merge Errors.

Wouldn't it be nifty if you could have an r-click option or input of "reverse order" or "merge from bottom"?

I assume that it behinds the scenes makes an array of errors and looks for the 1st one, so this would only add a 'reverse array' inside the function. To not have that ability forces you to do a Build array, Reverse array and Merge Error, which feels unnecessary.

I just found out about LabVIEW NXG's C Node. I know my team would love to have it in LabVIEW to use for bit masking in a familiar syntax. The Expression and MathScripts nodes have issue with 64-bit values and give unexpected results. A quick test in C Node does fix these issues.

Summary: I'd like to be able to build a PPL build-spec and get two files, "myLibrary.lvlibp" and "myLibrary-debug.lvlibp" (or maybe myLibrary.lvlibp-debug?), where colocation of the second file allows debugging use, but distribution of the first is sufficient to run without debugging tools.


Longer description/explanation/motivation:

When we build Packed Project Libraries (PPLs) we can choose to include or remove debugging information.


Without the debugging information, we have an optimized-for-deployment PPL that has smaller size, perhaps faster performance/loading, etc.

With debugging information, we can debug in the development environment.


In order for these to be used in place of one-another, they must have the same name, and the expected location. That is, if I write code on my dev machine using the debug libraries, I must replace those with the release PPLs (or exclude them from any builds, a common option) and then copy the release versions. I must rely on things like location (or worse, file size) to determine which is rel/debug, or rename into location, and then handle these 'manually' in my build processes.


Further, if I want to build nipkg files containing lvlibp files, determining appropriate dependency management when there are alternative packages for each library, but they can be independently interchanged (e.g. for A->B->C, I can have A-debug -> B-release -> C-debug if I want, or A-rel -> B-rel -> C-rel), is as far I can tell impossible. This is in part due to the Debian packaging format, which does not have a concept of a preferred dependency (such that I could choose to make "release" packages prefer "release" dependencies, but accept "debug" too). The behaviour at install time is not defined (you can get either, based on unspecified and to me unknown details).

Debian packages handle this by providing a "myLibrary" package, and a "myLibrary-dbg" package, containing e.g. debugging symbols (but NOT the code required for the library to work - so a dbg package always(?) depends on the non-dbg version of the same package).


I'd like this to be possible with LabVIEW, which seemingly would require the ability to load debugging information from a secondary file.

If LabVIEW allowed the dev environment to preferentially (and silently) load "myLibrary.lvlibp-dbg" in place of "myLibrary.lvlibp", then changes to build time are still desirable, but no longer required - in that case we can simply put both files (debug, release versions) in the same directory with different names and choose which to deploy (ideally LabVIEW would also deploy the release versions (unmodified names) during e.g. executable builds). This costs some extra disk space, since the debug package is a superset of the release package, but disk space is cheap and NI engineering time presumably less so...

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)




My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).




If I am on Mac or Linux and I try to open a VI that calls a DLL inside of a Disabled Structure, then LabVIEW searches for the missing DLL.


This is really a waste of time and effort, since it will never find or be able to load the DLL on Mac.


LabVEIW should be smart enough to know that it's not going to file a *.dll (Windows dynamic linked library) or a *.so (Linux shared object) on a Mac -- Mac uses .framework as it's shared library files.


So, I would extend this a little further and say that LabVIEW should only search for shared libraries of the type for that platform (.framework on Mac, .dll on Windows, .so on Linux).


Note: if a Call Library Function is configured for cross-platform (meaning it's configured for with a "*" file extension like mylibrary.* so that it will find the correct extension on the target platform) then go ahead and search for it.








Problem Statement

Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE.  In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain?  Here's the solution...




Proposed Solution

Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.



The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.





It seems that if you have a VI (or function) inside of a disabled frame of a Diagram Disable Structure or Conditional Disable Structure then the Find and Find All Instances features in LabVIEW will not report them. I'm OK if this is the default behavior, but maybe the Find dialog should have an option/checkbox to search inside of Disabled Structures.


Note: This is really important for cross-platform and embedded target development where there's lots of use of Disabled Structures.



Scenario: I've got a parent class and multiple child classes.  These child classes override a VI in the parent class.


If I decide I'd like to rename this VI, I currently have to track down every instance of it (in the parent and all children that override it), and then rename all of them individually.  It'd be a huge time-saver if I could just check a box (or select a different menu item) to rename this VI everywhere it exists throughout the hierarchy!

This idea was posted years ago and declined for lack of interest  (it got 6 out of 7 necessary, but I would have been the 7th!).  I would like to bring it back, I would like my application to have access to it's own version number.  In fact you can open the project programatically and see some build properties but not that one.  I can then grab the version from the build properties and set the default values on my FPGA code before compiling.


I was trying to make a pre-build VI that would look at the build properties and copy the version data into a control.  Can't be done.  I find this very useful to make sure that my RT system and my FPGA code have the correct versions.


Same as with an about box, or version checking for compatibility.


The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform.  Not useful for RT linux or Mac.  The version is not available until the executable is built which does not work for FPGA.


At the moment my only recourse is to hand copy the version from the build properties and then set those as a series of 4 integers on the FP.  (Then select them all and set their values to default, hence the other suggestion about right click)

When you select several items the "right-click" functionality is available only for common operations.  One of those common operations for several controls and indicators would be to set the current value to default or set the default value to the current value.  Both of these are available from the menu option for multiple selections.


However, this option is removed from the right click option when multiple items are selected.  Why?  Simple UI configuration.


Make the VI 'Write' useable from run-time. As it is now, not being able to use it, prevents implementation of menu automation in built applications (think support applications created for making LabVIEW easier to use).


I hope there isn't a technical reason for it not being useable as it's just creating some text files...


Longer and with background:

I've worked on automating the mnu-file creation. When I was done and had a working solution I started implementing it in our source management applications. Here I found that I could only use the automation from the development environment. (Yes I should have checked that before I started implementing.)


I've used the tool ( to create menu files for all our tools/packages and it has made it easy to refresh from folder structure when new files are added. However I cannot implement it as an automatic part of our built source management applications so newly committed files could automatically be added to the menu files and auto-linked into the labview folders. Which is what I would very much like to do.


So could you please make 'Write' useable from run-time to make menu automation just that much better? I'm hoping there is a way to do this as it is, as I see it, just generating text files...


Who wouldn't want this to auto update on commits?:



Best regards

Henrik Dueholm

The palette API VIs (Read & Write return built in function and control items as "BUILT_IN_FUNC_xxxx_x_x..." paths. There is no easy method to fetch the item name or icon for built in items. The private invoke node method APP : Palette : Get Palette Item Icon only accepts the Item Name.


This idea is to either:

    Idea 1: Add an application method to return the Item Name given the palette's Item Path (and vice versa).


    Idea 2: Extend the App : Palette : Get Palette Item Icon invoke node to accept either the Item Name -or- Item Path when fetching the palette item's icon.


New Idea Get Palette Icon.png

When reopening a project, the position of the window is retained from the last save of the project, the items in the project tree but not the status of the disclosure rectangles.  I usually like to have open the "chassis" and FPGA components as well as my top level software folders, and build definitions.  I keep sub-vi folder and hardware module folders closed.


It would be a time saver (and relatively simple) to preserve the status of those personal preferences so that reopening a project takes you to the same state you left it in.


Hopefully this is a moderate reward very low effort request.

It would be very helpful to be able to change formatting (different background, font, etc.) on individual items in a listbox. My use case would be listing a bunch of files in a listbox. Some of these files need to be brought to somebodies attention but most don't. The user also needs to view the files around the highlighted file so just listing the files that need attention is unhelpful. 


In the image below imaging that the file highlighted needed review. I would want to use any logic including string matching, or other logic to highlight the background color of just that item.


Image 3.png

Consolidate all LabVIEW G files into two file extensions:

  • Source LabVIEW File (*.xx) - Human readable source code files (e.g. *.vi)
  • Compiled LabVIEW File (*.xxc) - Compressed compiled binary files (e.g. *.vic) 


LabVIEW is proprietary. I need LabVIEW to open LabVIEW files. There are +15 LabVIEW file extensions to create LabVIEW G code. Recognizable LabVIEW extensions are worthless because I still need LabVIEW to open and edit the files. Some LabVIEW files contain compiled code, whereas other LabVIEW files are glorified name-spacers; some are UI components, while others embed compiled LabVIEW code into other LabVIEW files.


With every new LabVIEW version, capabilities are added that inherently cause inconsistencies between LabVIEW file types, environments and overall behavior. Let me explain. 



  1. Current LabVIEW file types don't adhere to consistent behavior:
    • Libraries (lvlib, lvclass, xnode, xctl) are xml files (human readable) but also contain encoded compressed data (non-human readable)
    • VIs (vi, vit, vim, ctl, ctt) are binary files that can contain compiled code (or not)
    • Libraries (lvclass) add dynamic capabilities like dynamically dispatched VIs and can embed class private data controls (or not for interfaces) using the same extension, rendering the extension useless
  2. Inconsistent code redistribution
    • Distribution libraries (llb, lvlibp) embed compiled code differently
    • Packed libraries (lvlibp) resolve system paths differently that source
    • Libraries (lvlib, lvclass) lack the capabilities to embed reusable libraries for redistribution - Similar to Python's PIP library
    • Some 3rd party applications (like VIPM) to manage distribution inconsistencies add more file types and compounds the redistribution problem
  3. Compatibility discrepancies
    • VI (Poly, Express), Class (Class, Interface) already introduces development idiosyncrasies that could be resolved with a one "file" fits all methodology.
    • More file extensions equals more variability, increased maintenance time, and puts ownership on developer community to find discrepancies

Proposed Solution:

  1. Consolidate current LabVIEW G source files (vi, vit, vim, ctl, ctt, lvclass, lvlib, xnode, xctl) into a single Source LabVIEW File (*.xx) that is human readable (i.e. xml) that contains no encoded, compiled or compressed data. - Similar to NXG's xml format
  2. Introduce Source LabVIEW File (*.xx) nesting/namespacing to remove the need for external Library files (lvclass, lvlib, xnode, xctl) - Similar to how C# or Python files allow for multiple methods within a single file.
  3. Add a build spec component to generate a Compiled LabVIEW File (*.xxc) that embeds the Source LabVIEW Files and Compiled Object Cache - Similar to Python wheels/pip package manager
  4. Allow developers to use the Source LabVIEW File (*.xx) or Compiled LabVIEW File (*.xxc) interchangeably in their development projects - Similar to how Python's *.py or *.pyc can be called


A single LabVIEW Source File (*.xx)...

  • can be human readable (i.e. xml) - Editor agnostic
  • can embed one or more LabVIEW Source Files - Single file libraries
  • replaces *.vi, *.vit, *.vim, *.ctl, *.ctt, *.lvlib, *.lvclass, *.xnode, *.xctl
  • adheres to common coding language extensions (C#=cs, Python=py, Java=java)

A single LabVIEW Compiled Files (*.xxc)...

  • is a specific build specification for packaging and distribution
  • contains the source files (optional) and compiled object cache
  • can embed run-time components - Package distribution
  • adheres to common coding practices (Python=.pyc, Java=.jar)
  • replaces *.lvlibp, *.llb, [*.exe]


LabVIEW currently has +15 extensions to develop G code:

(Not including, LV Projects, NXG, VeriStand, TestStand, LabWindows/CVI, etc.):

- Virtual Instrument (*.vi)

- Virtual Instrument Template (*.vit)

- Malleable Virtual Instrument (*.vim)

- Control (*.ctl)

- Control Template (*.ctt)

- Virtual Instrument Library (*.llb)

- Library (*.lvlib)

- Class (*.lvclass)

- XNode (*.xnode)

- XControl (*.xctl)

- Packed Library (*.lvlibp)

- Palette Menu (*.mnu)

- Run-Time Menu (*.rtm)

- Data (*.tdm, *.tdms, *.lvm, *.bin3, *.rc)


Should we consolidate?

Quite often, in order to locate a particular variable in an array I use the For Loop with Conditional terminal and output the last value of the comparison wired to the conditional terminal to identify whether the value has been found or if we've iterated through the array, without finding the value. - i.e. a really basic example which could probably be done better another way (a better example might be with multiple conditions to satisfy which I quite often have), but hopefully gets the point across:-


It works, but it always looks a bit messy to me, so wondering if there could be an option which would allow you to attach the conditional to the border and allow you to a bit more elegantly pass whether the conditional was triggered out of the for loop.