LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Multi-layered diagram visualization

I once started defining the abstraction level depth of VI's, searching someones coded several subvi's deep and keeping track of the hiearchy in you mind can be difficult, depending on the developers experience. It would be possible to make a visualistion aid that make use on a 3D-like stack of semi-transparent layers of the call chain diagrams, where one can scroll back over the call chain, and with the same scroll action move back to the deeper VI of interest. If the visualized callers use a clever way of highlighting the wire(s) that is(are) selected, in example by 'wobbling' or highlighting the interrfacing wires, then such a visualization excersise can help the programmer to quickly remember to caller code context while working on a deeper level. This might empower lesser experienced developer to investigate code that normally is too complex to grasp.

Look at it of making a LabVIEW diagram show up like a 3D design, where the programmer can see and track the data flow through another dimension.
Since a 3D perspective view with semi-transparency is technical feasible, this is an unused dimension that can be used to improve the program insight to programmers.
This would not be practical for lower level vi's in respect to where one is programming (would become too complicated) but it would certainly work for higher level VI's since it then simply follows the call chain.

View All (4)

Whereas I readily admit this is a problem between keyboard and chair situation, I occasionally find myself using the Ctrl + I (insert) when having selected a node and intending to Ctrl + P (replace) the node. Likewise, I will sometimes select a wire, identify the VI I am intending to insert and type Ctrl + P. This means I have to start over each time.

It would be nice if I tried to insert into a VI instead of a wire, it was smart enough to do a replace. Likewise, if I tried to do a replace on a wire by identifying a VI, it would insert it instead.

LLM-controlled LabVIEW scripting layer

There are many tasks in LabVIEW that are tedious and manual due to its graphical nature. This is something Nigel or another LLM-controlled scripting feature could change.

Allow it to perform structural changes and wiring on the block diagram via natural language commands. Expand it’s capabilities beyond explanation and simple code suggestions to direct, intelligent manipulation of the Front Panel and Block Diagram. The user should be able to describe desired behavior in plain English, and the AI should execute or generate the appropriate structure.

One example would be wiring and bundling: “Wire all controls whose names contain ‘sensor’ to a Bundle By Name node using the matching cluster element names.”

Another might be diagram layout: “Select all terminals containing ‘temp’ and arrange them by the last number in their name vertically on the right side of the diagram with tight spacing.”

Desired Capabilities:

Name-based matching and filtering of controls, indicators, and cluster elements.
Intelligent wiring (Bundle By Name, Unbundle By Name, auto-wiring by name).
Creation of VIMs / reusable subVIs with dynamic behavior.
Structural changes (add loops, case structures, bundling logic, etc.).
Optional preview + confirmation before applying changes to the diagram.
Works on both Front Panel and Block Diagram.

This would turn the AI into a true productivity multiplier — especially for large VIs and configuration-heavy applications. Importantly, it does not necessarily require it to be that advanced; it would mainly be an LLM-controlled driver for VI scripting (leveraging LabVIEW’s existing VI Server and object model).

View All (3)

There are lots of very old Idea Exchange entries for plots that seem very promising.

Some of these go back to 2009, and this wasn't an exhaustive search. Some of these ideas were posted before some of our forum members were even born! 😉

That handful I picked has a total of 317 Kudos- but they're spread out over a large number of individual posts, so this Idea entry is sort of a combo of all of them. Basically, there are LOTS of great ideas from the community, but unfortunately most don't get any traction from NI.

The request is to Open Source the plotting tools, similarly to the Icon Editor or the Actor Framework. I know I'd be thrilled to be able to hack around with the plots. I'm sure there are some gnarly secrets under the hood, but that's part of the fun 🙂

The request:

When you add a VI server reference to a VI, it shows up as "This VI". Why not allow it to be searchable in Quick Drop with the text "This VI" as well?

_carl_0-1785165839087.png

My experience:

I find myself often wanting to add this to a VI, but when I open up Quick Drop, the first thing that comes to mind is "This VI" because that's how it shows up in the block diagram. Inevitably I then spend 30 seconds trying to remember what exactly it's called before either eventually remembering it's "VI Server Reference", or giving up and going to the Tools Palette to find it.

Another modernization feature (not on this comprehensive list already...) that would be nice to see in XY graphs:

We currently have to select an interpolation method per plot. Instead I would like to be able to say that if the next sample is less than a given delta apart from the previous it should draw a diagonal between the points, but if the delta is larger (due to deadband filtering e.g.) it should draw the previous sample value as a flat line until the new sample...

This could be added as an option in the manual selection method that visually showed a mix and had a name like dynamic or conditional (none of the options currently have a descriptive name or tip strip by the way so that is an idea as well; with an enum input for the property...). If conditional was chosen it could pop up a dialog asking for a definition of the condition. Similarily this would have to be a new interpolation option and an input of a threshold or list of such to set up the conditions. Just having two methods with a threshold would normally suffice...

graph interpolation.png

Yes, we can off course achieve this today by doing the interpolation prior to feeding the data to the graph, but building this into the graph will simplify and seriously optimize the process.

View All (3)

Within the VISA Read and VISA Write nodes, you can currently choose the Synchronous I/O mode for each individual read or write operation by selecting either Asynchronous or Synchronous (see attached screenshot).

It would be helpful to allow this setting to be configured at the project level rather than requiring it to be set on every VISA Read and VISA Write node. While there are certainly edge cases where a project is best served with a mix of synchronous and asynchronous VISA operations, the vast majority of applications would best use one mode consistently throughout the project.

A related enhancement would be to allow the default value for this setting to be configured in the LabVIEW Options dialog, rather than always defaulting to Asynchronous.

Another possibility would be to change the default for new LabVIEW code to Synchronous. Although synchronous communication can be slightly slower in some situations, it is generally more reliable. Since LabVIEW is used primarily in test applications, reliability is likely more important than maximizing communication speed.

View All (2)

Labview IDE

A parent IDE window with 2 child windows each supporting "tabs", one for all Front Panels and another for all Block Diagrams. A 3rd child window for the project manager. All can be docked or undocked.

Operation:

Selecting a VI tab on one window would automatically select the corresponding VI tab on the other window so they always track together.

The child windows can be docked side by side or one above the other within the parent window or they can be undocked to place on separate monitors.

When child windows are docked, have a setting to memorize their position.

When in the “Highlight Execution” mode, the VI (Block diagram and associated Front panel) of the current execution path is automatically opened, if not already, and the tab selected.

Despite being growable for adding outputs (capturing groups), the "Match Regular Expression" XNode is missing some convenient features from other growable functions:

1. Cannot add a new element at the top while resizing the node:

Resize from top.gif

2. Missing "Add/Remove Element" right-click menus:

raphschru_0-1781017278636.png raphschru_1-1781017452535.png

The lack of these features forces us to rewire everything manually.

This idea has the same motivation as this previous one: making the editor more ergonomic and predictable.

Regards,

Raphaël.

View All (5)

If you set up Windows 11 as Microsoft suggests (at your peril), your user Documents folder will be synchronized to OneDrive. Unfortunately this is also the location of the default data directory for LabVIEW. Various side effects ensue but the one I've run into is the compiled object cache, a SQLite database that can get into the gigabytes, winds up getting synchronized which is a complete waste of bandwidth.

To deal with this I think there should be a warning dialog with "don't show again" checkbox when LabVIEW detects the default data directory is in a synchronized folder to prompt the user to choose a different location.

This idea is an extension of an existing one. Here the idea is to have alpha layer support in the Picture Control. But the truth is NI already added it in 2020 but never put it on the palette, or documented it. I made a quick demo showing how you can have a highlight over an element of an array showing which one is moused over here. The main VI that powers this is here:

https://youtu.be/gqJWBbqoR4s?si=_JT8-K7FoNfaPVhz

National Instruments\LabVIEW 2020\vi.lib\picture\PNG\Draw Flattened Blended Pixmap.vi

But I would like this idea to extend beyond just putting this VI on the palette or documenting it. I think NI should add more alpha layer functions too. Things like convert LV Data to 32 bit, set or adjust the transparency level, and make a single VI that can call the normal Draw Flatten for a 24 bit or less image, and call the Blended one if 32 bit so that a single VI can be used. I have a couple of these type of features in a pack on VIPM.IO but I'd rather they be built in to LabVIEW.

And lastly. If we are going to think about places that alpha information can be used, I think the first place I'd like it is to be able to get an image of a control, but have the background be transparent using something like this:

wiebeCARYA_1-1741949642891.png

Combining this with the other tools would mean there's more flexibility in making image based controls.

It would be nice if there was some option to configure the separator behavior of combo boxes. Currently, entering a hyphen (-) as an item turns into a separator automatically, and there is no way to configure that. What I think would be best in terms of configuration options is a "Separator Value" property in the Edit Items tab of the Properties dialog. The hyphen could be the default value, and it could be changed to an alternate character or character sequence if the developer needs the hyphen to appear as just that for whatever reason. If the value of the property is empty, there are simply no separator lines created.

FireFistRedhawk_0-1779113435039.png

There is also a bug involving the hyphen as the separator value. When a combo box has the Allow Undefined Strings property unchecked and also has a separator as one of the items, a hyphen is still treated as a valid entry since it is technically one of the values present. This bug exists in the most up-to-date version of 2026 at time of writing, 26.1.2f2. I think the existence of this bug warrants taking a look at the separator behavior in general, but also possibly adding this idea as an enhancement to it.

View All (7)

Having consistent (and therefore predictable) right-click menus is essential for maximizing coding efficiency.

Most structures have the following right-click menu items:

Visible Items
Help
Examples
Description and Tip...
---------------------------
Add Breakpoint
---------------------------
Structures Palette
Auto Grow
Exclude from Diagram Cleanup
<specific menu 1>
⋮
<specific menu N>
Replace with <other structure type 1>
⋮
Replace with <other structure type N>
Remove <structure type>
---------------------------
<other specific menus>

The right-click menu however has some inconsistencies regarding item order and menu separators for certain structure types:

1. "In Place Element Structure" has "Replace" and "Remove" items reversed:

raphschru_0-1778671181846.png

The "Remove" item should always be the last one in the item group (right before the separator) since it is a very common action and the separator offers a quick visual reference point.

2. Depending on whether you click on the structure border, the frame name label or the subdiagram label, sometimes an extra item separator appears for no reason:

raphschru_3-1778673447637.png raphschru_6-1778673672106.png raphschru_5-1778673565395.png

The grouping of the generic items shouldn't vary depending on where you click on the structure. Here we sometimes have 4 item groups instead of 3, which hinders quick menu identification and selection.

3. This is more a general remark, but I think items specific to a structure type shouldn't be mixed with the generic ones in the first 3 groups (except maybe for the "Replace" items, since they are related to the "Remove" action).

So any specific menu item should belong after the first 3 groups:

raphschru_2-1778672934373.png raphschru_7-1778673846675.png

raphschru_8-1778673934000.png raphschru_9-1778673982744.png

This last remark could be subject to discussion though, as configuring iteration parallelism and shared clone allocation could be considered a "primary" action (therefore requiring to be closest to the top), even if it is specific to certain structure types.

Regards,

Raphaël.

View All (4)

Keep DDE supported

View All (1)

64-bit DSC version

View All (1)

Remove unconnected on Index array

View All (2)

Recent improvements to editing string constants on the block diagram—such as enabling Ctrl+A to select all text—have been very helpful. When testing parsers, I frequently work with large string constants, and smooth navigation becomes important.

Currently, scrolling inside a string constant always moves by a single line, regardless of the operating system’s configured “number of lines to scroll per mouse wheel notch.”

Please update LabVIEW so that scrolling within a string constant honors the OS-level scroll-wheel configuration. This would make navigating large constants more consistent with user expectations and system-wide behavior.

LabVIEW Idea Exchange

Multi-layered diagram visualization

Overload the Insert and Replace Quick Drop Shortcuts

LLM-controlled LabVIEW scripting layer

Open Source the LabVIEW Plotting Tools

Quick Drop: Let "This VI" find "VI Server Reference"

XY graph support for segmented /conditional interpolation based on delta-x thresholds

Set Visa "Synchronous I/O" mode for entire project.

Labview IDE

Align growable behavior of "Match Regular Expression" to other growable functions

LabVIEW should handle OneDrive-sync'd Documents folder better

Officially Support and Improve Alpha in Picture Controls

Add option for combo box separator value

Allow LabVIEW to work with Windows Clipboard History

Improve right-click menu consistency for structures

Keep DDE supported

Type aware layering of values displayed in highlight execution mode

64-bit DSC version

Remove unconnected on Index array

Respect OS “Lines Scrolled” Setting When Scrolling String Constants

Fix "Size to Text" lost on Change to Array