LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Currently, new sublasses require the user to find the correct parent class in the class tree. In larger projects, this can be really painfull.

I suggest two simple things to improve this very common task:

1. Make the class tree searchable: Put a filter string input above where you can filter the tree by name

2. Add a "Create New Sub-Class from this Class" Item to the context menu in project explorer. This could simpy open the class tree with the matching class already selected. Something like this would also be great for interfaces.

View All (2)

Starting from LV 2023 Q1, the terminals height of some nodes was harmonized to 16 pixels to improve diagram readability by reducing the amount of needed wire bends.

Some candidates for this harmonization were omitted though:

- Data nodes of timed structures (timed loop, timed sequence).

- I think pretty much all of FPGA nodes (IO nodes / methods / properties, FIFO / memory / register / handshake methods, IP integration, high-troughput math nodes, ...).

Example with a Timed Loop:

The idea is to also allow RT and FPGA developments to benefit from this harmonization.

View All (4)

Delete breakpoints from debug window

Hi all,
when I use breakpoints for debugging, I found that the breakpoints sometimes automatical re-appear after they are deleted from the breakpoint manager. I did some tests and found that they only appear again, when there is no other change in that VI, so the VI is not marked with the * in the title, which indicates unsaved changes. They will also not reappear when the VI is saved manually after the breakpoint is deleted.
So the suggestion is that a VI should also be marked as unsaved after deleting a breakpoint.

Regards, Patrick

Hi all,

I' normally using one or multipe queued message handler with a clustered enum (which is saved as Type Def.) and a variant as a basic architecture of my programs. This makes sense and it is relatively easy to search forward and check a program step by step. Unfortunately, it is not so easy to go stepwise back in the program for debugging., especially if there are multiple callers of a function.
Therefore I wish I have a function, where I can search for a single item of this enum Type Def.
I know that there is a possibility to search a text and of course it will find these items, but is also finds all other kind of things labeled the same.

I had a small chat with a engineer of NI already and we had an idea to gerneralize this a little to give it more use cases.
In the current situation, we can search for a:
- Type Def. , but then it will find each item of the enum OR
- text, but then it will find all items labeled with this text.

So here is our idea:
Create a possibility in the search window to combine these 2 search formats with a boolean operator, in our special case, this would be AND. But in other cases it might be also useful to have some other operators.

You are welcome to share any thoughts about it.

Best Regards, Patrick

Problem

I find myself wanting to Ctrl+Drag to add/remove diagram space INSIDE of a structure without actually resizing the structure itself AND without modifying any other frames – I just want to clean up the visible diagram that I am working on.

However, this is not how LabVIEW currently works – the structure itself is also resized, and the space within other frames of the structure are resized as well (outward/inward from the same point as the Ctrl+Drag action), which can mess up both the code in other frames as well as the code outside the structure.

Proposed Solutions

Option 1: Lock Structure Size Add the ability to lock the size of structures (or perhaps only lock them from growing during creating/removing space), so that I can use Ctrl+Drag to create/remove space without impacting the structure and the code around it. This would be similar to "Auto Grow" but would perhaps be an "Allow Grow" or "Lock Size" setting.

Option 2: Modifier Key Use the Shift modifier during Ctrl+Drag and Ctrl+Alt+Drag to NOT resize the containing structure. This would maintain backward compatibility while adding the new functionality.

Why This Matters

When working on complex VIs with multiple frames in structures, it's frustrating to have simple diagram space cleanup operations affect the entire structure and surrounding code. This feature would allow developers to better organize/tidy the code within individual frames without the ripple effect of resizing everything (in other frames and outside the structure).

View All (2)

Clear Probe Watch Window

View All (3)

Static File Reference

Open Class in Runtime

There is a managed way to open a library both in development and in runtime environment via Library.Open method. The same method is available for Class Libraries but without the possibility to open the Class in runtime environment although the Class Library is a specialization of the Library.

Therefore the getting the hierarchy and/or the members of a Class could be performed by terrifying non-managed way in Runtime environment.

It would be nice to get the same functionality from this method as found by the Libraries.

The Desktop Execution Trace Toolkit (DETT) collects hundreds to thousands of data points that indicate memory allocations, queue references, events, and more. The data is always available and often is overwhelming. The only way to make sense of data quickly is to create custom probes that create highlights in the data, however, that is only after you know which VI is worth probing further.

The idea:

Feed all the data normally collected by the DETT about a LabVIEW project directly into Nigel so that it can provide human-friendly suggestions explaining:

Level 1

How often a VI allocates memory in a repeated fashion

The time jitter between different events

VI's that could be good candidates for refactoring

Level 2

Improvements to the code within that VI based on best practices for optimal compiler operations.

This is based off a discussion at GDevCon #6 on September 10th, 2025.

View All (5)

Property node for push button LED color

I want to be able to programmatically change the color of the LEDs on push buttons.

The colors[4] property will change the color of the housing, but not the LED itself.

This push button is one of the controls that is both a control and an indicator rolled into one.

In my particular case, I want to represent a third state. I have a valve that can be open, closed, or in transit.

There are two actuation states of open and close, but three indicator states.

I think making it a property I can control is a powerful solution. Not only will it solve my use case, but I can have all different colors of Booleans without needing to use Customize Control and the Control Editor to modify the colors.

Extra credit request: Can we make just the LED blink? Right now, the blinking property blinks the entire control, but wouldn't it be cool if just the LED blinked? This is what those same two controls look like when blinking:

Maybe it's a new property just for LEDs that's separate from "Blinking". I'd be okay with that if you want to preserve current behavior.

Here are some related Idea Exchange posts related to a tri-state Boolean. They're not quite what I want, but I thought I'd link to them for reference:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Tri-State-Boolean/idi-p/1139952

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Special-LED-control-with-three-states-Default-ON-OFF/idi-p/991307

The zooming feature in LabVIEW was way past due, particularly with the advent of 4k displays (and the rapid degradation of my sight!), but was implemented very poorly. As mentioned in other idea exchanges, the font size handling is awful, and regardless does not address the ancient-looking pixelated block diagram interface. Also the zoom resolution has too many steps for how drastically the view contorts with each step.

The entire system should be overhauled as vector-based so it looks crisp at any zoom level and zooms smoothly between zoom levels. The shining light example of smooth-zooming is Miro which handles text sizes and detail-loading even better than Google Maps.

I am really looking forward to not squinting at pixels, and LabVIEW is literally the last offender I work with.

View All (4)

Filter function to Bookmark Manager

The new debug window in LabVIEW 2025 Q3 automatically expands arrays to show all elements across multiple lines. While this full view can be helpful, it often becomes disruptive during debugging.

I have attached a video that shows a side-by-side comparison. The left side is LabVIEW 2025 Q3, and the right side is LabVIEW 2024 Q3.

As you can see, when an array contains many elements, the new multi-line display consumes a large amount of vertical space on the block diagram. This pushes other probes and data displays down, causing their positions to shift and making it difficult to monitor them. There are many cases where I only need to see that the array contains data, not every single element, and I would prefer the more compact, single-line view.

I propose adding a feature to allow users to select the display mode for arrays in the debug window. It would be ideal to have a toggle or option to switch between the new multi-line view and the classic single-line view, similar to how it worked in LabVIEW 2024 Q3 and older versions.

This would provide the flexibility to choose the most appropriate view for the situation, greatly improving the debugging workflow and the visibility of other data on the diagram.

View All (1)

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

- Queue

- Notifier

- User event

- DVR

- Datalog file reference

- Strictly-typed control refnum

- Strictly-typed VI refnum

- Shared variable

- Network stream (reader/writer)

- RT FIFO

- FPGA IO / register / memory / FIFO / handshake

- ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.

View All (8)

pre-launch hash checker

Currently, when right-clicking a Messenger channel tunnel in LabVIEW, the context menu only offers the option to create a channel reader. However, Messenger channels support multiple writers, so it would be both logical and convenient to include a "Create Channel Writer" option directly in the popup menu.

At present, users must manually insert an element of the channel wire’s type and then create a writer from its output—an unnecessarily cumbersome workaround for a simple task.

This seems like an oversight rather than a technical limitation, and adding this feature would streamline development and improve usability for anyone working with Messenger channels.

At the moment the quick change plugin leaves the cursor where the label was. In order to select the control type, you must move to the list and select the type manually. It would be nice if the window captured the mouse focus and moved the cursor through the items with the scroll wheel. This would make the operation much quicker. An alternative would be to allowing tabbing through the items and use the space bar to select the desired item. Both of these options eliminate the need to aim with the cursor. For the scroll wheel options, bonus points if it returns the cursor to the label position when finished.

You cannot currently install MAX as a standalone product- you need to install it along with something else. I need MAX on basically all computers I build my installers for, so I always go into the Additional Installers menu on the Application Builder, then pick (usually) "DAQmx with Configuration Support". Unfortunately, this also means I have to uncheck "Automatically select additional installers" so I can go find the "Configuration Support" item.

I almost always want to let the App Builder pick my additional installers for me, so I will check "Automatically select", then uncheck it, then go check the box for "...with Configuration Support" for one of the items that got automatically selected.

I'd like a box that lets me prefer the "With configuration support" version of whatever I'm building so I can make sure MAX gets installed. For my use, it doesn't seem to matter if I pick "DAQmx with config support", "VISA with config support", etc.

I'd ask to make MAX a standalone installer, but that would require me to uncheck the "automatic" box to add MAX to the list, which doesn't really help. I just want to say "Hey Appbuilder, figure out whatever you need, and ALSO install MAX."

Pro-grade mockup shown below:

View All (2)

Optional DVR input to controls

View All (4)

Similar ideas have already been posted but non of them totally hits what I'm missing.

As always - what is the current situation?:
- LabVIEW is installed under "C:\Program Files (x86)\..." - this is a folder where admin rights are usually required to modify it.

- in the named folder the standard VIs are included: vi.lib / user.lib / instr.lib

- my project lays somewhere else - e.g. "C:\myLVProjects\project1", "C:\myLVProjects\project2", ...

- my first project is LabVIEW32 bit, my second is LV64bit,
- one project needs to have the binary code separated from the VI, the other one not
- one projects needs some toolkits from the VI Package manager, the other one not or maybe even incompatible ones to the first project

- one project needs VIs from an additional search path, the other one too but with a different version

long story short:
There are many situations where the configurations of two or more projects conflict with each other. Therefore, switching between two projects can be quite effortful — from adjusting configurations to (de)installing toolkits.

What I like to propose is the following:
Having a new option in the LabVIEW start screen "Create a new development environment".
The only the user has to do is to select a folder on a drive with enough free space.
LabVIEW shall now setup an entire code- and configuration environment. Means it copies vi.lib, user.lib, instruments.lib to this folder. It create a LabVIEW.ini and a link to the exe using this INI. It creates a folder for the compiled object code cache and so on. Installing add-ons from VI package manager shall also be stored in this new folder structure.
And of course, there shall be a place where I can manually add some libraries, my project files and finally also my build results.
If LabVIEW is now started from the named link it only uses the VIs from the environment folder as long relative paths are used (which shall be default).

Again in short: I expect an encapsulated environment that contains everything that is needed to develop one project entirely independent from a second and third project.

View All (5)

LabVIEW Idea Exchange

Make creating subclasses less painfull

Normalize terminals height for timed structures and FPGA nodes

Delete breakpoints from debug window

Extend the search function (Ctrl+F) to get more detailed search results / Search a single item of an enum Type Def.

Add/Remove Diagram Space Inside Structures Without Resizing the Structure

Problem

Proposed Solutions

Why This Matters

Clear Probe Watch Window

Static File Reference

Open Class in Runtime

Desktop Execution Trace Toolkit (DETT) insights provided by Nigel, the AI advisor

Property node for push button LED color

Make block diagram vector-based - for cleaner view on high res monitors, cleaner zooming

Filter function to Bookmark Manager

Add an Option to Display Arrays in a Single Line in the Debug Window

New primitive to get the contained data type of a strictly-typed reference

pre-launch hash checker

Add "Create Channel Writer" Option to Messenger Channel Tunnel Context Menu

Free Label Quick Change - Enable Scrolling and or tabbing.

Checkbox to let the App Builder prefer the "x with Configuration Support" to auto-install MAX

Optional DVR input to controls

Support "Development Environments" / "Development Sand Boxes"