LabVIEW Idea Exchange

Community Browser
Top Authors
Showing results for 
Search instead for 
Did you mean: 
Post an idea

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.


First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.


Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!


When is LabVIEW going to get with the times?

The VI Properties window allows to select between local help file and Web-based Help URL.




LabVIEW Class, Library and Project doesn't allow to use Web-based URL.






The idea is to have the same behavior for all source file.

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Combined v2.png









  • The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
  • The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
  • “Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

  • .NET: System.DateTime.Now
  • C++: std::chrono::system_clock::now()
  • Python:

Notice that the equivalent function names contain the word "now" and omit "in seconds".


Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.


Nevertheless, I would be happy with the following names too:

  • “Get Timestamp Now”
  • “Get Current Date/Time”
  • “Get Current Timestamp”


  • Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.

It takes me too much time recognizing to which class and library this opened VI is belonging to. This is espacially the case when working with LVOOP, having the same VI in different classes.

A subtle improvement would be to have bold colons or 1.5x space between colons and path components in order to improve readability.















































  • Removes the need to use a separate Color Box Constant and Bundle By Name node when writing to VI server properties that take the LvFontTypeDef.ctl as an input.
  • More intuitive representation (a colour displayed as a visual colour rather than just a number).


  • The underlying data type of the Color Box is U32. Hopefully this means that this change would be "transparent" to the compiler. The change would affect only the visual appearance and  would improve the human interaction with this typedef cluster.

Bug replication steps:

  • Ensure that the "Connector pane terminals default to Required" option is ticked (found in Tools >> Options >> Front Panel).
  • Connect an indicator to a VI's connector pane.
  • Right-click the indicator and select "Change to Control".
  • The indicator changes to a control, but the connector pane terminal is Recommended. It should be Required (should obey the environment setting).


  • Mis-connecting an indicator to the connector pane while believing it is a control can occur moderately frequently, especially when working with front panel elements that do not look very different when they are controls vs. indicators, for example: variants, objects, typedef clusters, system-style strings or paths.

1 (edited).png

The array "Startup/Always Included" carries these Vi's into pre/post build action VI's.

The order of the vi's in this array depends on the order they have been added to/created in the project when, not the order they can be seen on the project window itself.

Here's the project window:


Here's the order within prebuild vi:



The order is NOT the same. "startup" is the first but if you delete from the project and then re-add it, it will become the last.


I suggest that the order in pre/post build VI should be:

first -

following: always included vi's in the same order they appear in the project window.


Also, the always included list should have a 'mechanism' to change the order of the vi's in the list - be it up/down arrow buttons on the side that would move the selected vi or a similar command in a "right click" drop down menu.


In this way, any pre/post build action that may involve any of these vi's can be clearly defined and remain stable during the lifetime of the project without running into the risk of getting the wrong vi to "work" on or having to edit the pre/post build vi to add or edit the vi's names every time there is a change in the startup/always included list.


Currently the quickest way to open a typedef is right-click >> Open Type Def.


Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing typedef constant or terminal (Block Diagram) or control/indicator (Front Panel) would be quicker.



































  • The gesture could open the private data definition (ctl file) of a class when double-clicking on an object constant, terminal, or control/indicator.
  • Opening the typedef for inspection/modification is one of the most common actions when working with typedef clusters and enums.

When using the insert quick-drop option, it works great when wiring something into a single wire.


However, when working with multiple wires, it just inserts a new VI on each wire. This could be improved upon to better support the standard LVOOP workflow where you'd want to pass two wires through each VI.


I find that this is the scenario where the quick-drop option could be most-useful, however the current implementation really isn't very useful in this scenario at the moment.


Currently the fastest way to open the Properties page of a front panel element (control, indicator, decoration) is right-click >> Properties.


Holding down a modifier key (Alt, Ctrl, Shift, or a combination of these) while double-clicking on the front panel element would be quicker.

































  • Opening the properties page of front panel elements is a common, repetitive task, especially when creating complex UIs where the size, colours, display format, data entry limits need to be changed.
  • Ideally the gesture would work on block diagram terminals too.
  • This idea is very similar to New keyboard shortcut: Alt + double-click to open Properties in Project Explorer. The difference is that this idea addresses opening the Properties page of front panel elements, whereas that idea addresses project items.

I've encountered quite a few limitations when debugging debuggable PPLs, and feel that a number of improvements could be made to this process. I often find myself having to open a second project with the specific dev library in it, and then toggling back and forth between the two which is both confusing and inefficient. This is just scratching the surface, but here are some improvements I'd like to see made:


  • Non-editing menu options should remain available. One I use quite commonly: right-click on a class cube, and select "Show Class Library". But it's not available:
    The workaround I use is to "Copy Data", press ctrl+n to create a new VI, drop the class cube there, and then right-click on that and select "Show Class Library", then toggle back to the temporary VI and close it.
  • VI Properties aren't available in VIs:
    I often want to double-check reentrancy settings on VIs to ensure everything's configured correctly.
  • Private class data isn't shown. I get why this isn't available in non-debuggable PPLs, and I understand that there's a healthy debate that can be had as to whether or not this should be available in debuggable PPLs. I'm of the opinion that private data should be available in debuggable PPLs as they are meant for debugging, not for distribution.
  • Private class methods don't show up in the project.  But if you click on the sub VI for a private method, you can open up the block diagram.  If the block diagram is accessible, it really should show up in the project. I often find myself searching for a VI in the project, and not finding it anywhere, because the method is private.
  • Unusual interactions. I've seen a number of scenarios where I'm prompted with requests that I shouldn't be asked.  For instance, if I double-click on a malleable VI in a PPL's block diagram, I get this popup:



Using "Edit Palette Set" is cumbersome and painstaking.


Specific use case example:   I create a class library that has an embedded menu file that I want to distribute as a compiled packed library (PPL) or even as a source code distribution for re use by other developers.     To make the mnu available in the functions palette, you have to manually recreate the menu file to link to the versions of the functions inside the distributed functions, which is painstaking for a larger library.


It would  really nice if we had the ability to generate or easily edit mnu files.  In the example, a simple search and replace of the paths that the functions in the palette link to would work

Currently the fastest way to insert a Bundle By Name node into an existing cluster wire is to use the QuickDrop Ctrl + I shortcut.


Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing cluster wire would be even quicker.













  • Inserting BBN nodes is a common, repetitive action when working with clusters. For example, when working inside the Message Handling Loop of a DQMH module.
  • The gesture should work for class wires too, but only if access scope rules allow it.
  • This idea is very much related to the "New gesture to create Unbundle By Name node (Ctrl + double-click when creating a cluster wire branch)". The difference is that this idea addresses inserting BBN nodes into existing wires. That idea addresses more easily terminating a new wire branch with a UBN or BBN node.


It's useful that we can open the Error List window via the Ctrl + L shortcut.





































It would be great to have keyboard shortcuts that allowed us to navigate to the next and previous errors (broken run arrow locations). This would be similar to how Ctrl + G and Ctrl + Shift + G can be used to navigate to the next and previous result in the Search Results window.


I would be happy with any key combinations chosen for this purpose.



Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).






Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂

This topic keeps coming up randomly.  A LabVIEW class keeps a mutation history so that it can load older versions of the class.  But how often does this actually need to be done?  I have never needed it.  Many others I have talked with have never needed it.  But it often causes problems as projects and histories get large.  For reference: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes.  The history is also just added bloat to your files (lvclass and any built files that use the lvclass) for something most of us do not need and sometimes causes build errors.


My proposal is to add an option to the class properties to keep the mutation history.  It can be enabled by default to keep the current behavior.  But allowing me to uncheck this option and then never have to worry about clearing the history again would be well worth it.

Edited Image 1.png


  • Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
  • Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
  • This idea is somewhat related to the following idea: "Show node names when dropped" option

Recently LabVIEW has added the following feature: When creating a new wire, double-clicking creates a terminal. This can be an indicator or a control, depending on what was selected. If the wire was started from a data sink (a structure tunnel or a subVI or node input terminal), holding down the Ctrl key while double-clicking creates a constant. This is very useful and saves time. Kudos!


When working with cluster wires, it would be useful if an Unbundle By Name node could be created by:

1. Start creating a new cluster wire or wire branch

2. Hold down a modifier key (Ctrl, Alt, Shift, or a combination thereof) and double-click


Step 1: Start creating a cluster wire

1 (edited).png












Step 2 - current behaviour: double-clicking creates a terminal. This is useful. Holding modifier keys down (Ctrl, Alt, Shift) does not alter the behaviour.

2 (edited).png












Step 2 - desired behaviour: Holding modifier key + double-click creates Unbundle By Name node

3 (edited).png













  • Creating UBN nodes is a common, repetitive action when working with clusters. This gesture would save time.
  • The screenshots above show a cluster wire being created starting from a control terminal. The gesture should, of course, work regardless of which object the wire branch was started from (e.g. tunnel, subVI output terminal, etc).
  • Perhaps the idea can be expanded to creating Bundle By Name nodes. Perhaps one modifier key (e.g. Ctrl) would create a UBN node, while another key (e.g. Alt) would create a BBN node.

The LabVIEW Icon Editor plays a central role in creating graphical icons for VIs.

Yet, it has some quirks that would be great to address, such as fixing a few issues affecting users on Linux.


Because the Icon Editor is written in LabVIEW, many LabVIEW users could actually help fix issues and suggest improvements more directly, if the Icon Editor source code were hosted on GitHub. This would allow people to submit issues and feature requests (even in the form of Pull Requests with the fixed/improved code).

By transitioning the Icon Editor to GitHub, NI could establish a process that allows for the incorporation of community improvements into the official LabVIEW releases.  This would improve quality and allow for more and better feedback from the community.

Note that NI has historically shared the Icon Editor code with each new LabVIEW release (here in the NI’s LabVIEW discussion forums).  However, there hasn’t ever been an effective mechanism for the community to contribute back their fixes and feature suggestions.  So, hopefully this would only take incremental effort for exponential gains!

Control and indicator references are currently 19 pixels tall. They should be 16 pixels tall. References would then align better with other items which are already 16 pixels tall, such as the Bundle By Name and Unbundle By Name nodes.


1 (edited).png


















This idea is inspired by this idea and this idea.