LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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)

It would be great if one could mark certain files as having an absolute path so that it is easier to move projects that use a common resource around in a multi developer/station environment.

A project might for example require a shared library or file that is installed by another application into c:\XXXX

Currently, all developers must place their project at the same relative folder depth to the shared resource to avoid linking issues. e.g If Developer A uses c:\Users\Dev A\Project\ then Developer B would need to use c:\Users\Dev B\Project\.. The project would complain about not finding the shared resource if Dev B was to use c:\Users\Dev B\Repos\Project instead for example.

Marking the shared files as having an absolute path would resolve this

pre-launch hash checker

At the moment, using Diagram Disable Structure with Channel Wires results in a broken arrow, which prevents compilation. However, it would be highly beneficial to allow temporarily disabling the transmission of values or messages to different parts of a program—for example, during debugging.

A tedious workaround used in the past involved connecting ))Channel.vi with ChannelOp.ctl from the generated Channel Wire library to the channel in the enabled case. This allowed bypassing the broken arrow issue.

However, since around 2025, these components have become natively private, making the workaround even more cumbersome and less viable.

I’d like to propose the following improvements:

Native compatibility between Channel Wires and Diagram Disable Structure.
Optional front panel connection for Channel Wire controls—i.e., they shouldn’t require a wired connection to function or compile.

These changes would streamline debugging and development workflows and reduce unnecessary complexity.

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.

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)

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)

fused multiply-add(FMA) for LabVIEW ?

LabVIEW native dataframe type

Since a few years, we have native support for Map and Set in LabVIEW.

How about adding a DataFrame type similar to other programming languages (possible even with a native interaction with Python)?

A DataFrame type would be a 2D value where columns can have different datatypes. Currently, one needs to build around this by creating an 1D array of a cluster (or class) type.

Access to the data would be with numerical indexing for the rows and field access (like in a cluster) for the columns.

KR, Benjamin

View All (5)

It's hard to believe that this is the first post to request something like this (pun intended), but I couldn't find it after a few queries.

The base idea would be that both the static and dynamic connectors used to connect the methods to the owning class shall be defaulting to the owner class, a.k.a. this object in text based languages. The main problem is the use case for refactoring. When moving around methods the class controls and indicators have to be replaced every time. It doesn't matter if I'm moving methods between classes or to interfaces it is the same pain: replace the connectors (with QuickDrop), then change the names to class names, then update the icon, finally move the VI to the new location.

I know that this could and maybe is already solved with scripting, but I think the development environment shall grant the option to change the control and indicator to this object that will always default to the owning class, without manual updates. Even the labels could be This in and This out, and replaced in real time with the actual class implementation on the block diagram of the calling VIs.

The proposed solution would also get rid of the error telling about the dynamic dispatch controls shall reference the owning class, since it would happen automatically.

View All (2)

Providing additional Context Help information on Controls that contains information as to their "type" (Classic, System, Silver, etc.) as well as their font, font-size, and control-type (indicator, ring, enum, etc.) would be useful. The utility of this is obvious if you have ever had to modify/update an existing GUI and want to maintain the look and feel when adding new controls -- this would allow you to easily see what was previously used for the existing controls on a GUI. This "verbose" information could possibly be turned on/off as a Tools->Options->Front Panel setting.

View All (2)

For anyone that has used CAD software, you know how much of a timesaver this feature is. It is very similar to quick drop but relies more on graphical selection than keyboard input (although, these shortcuts often allow text entry as well and have a configurable menu).

For example, pressing the "S" key in SolidWorks pops up a contextual, configurable menu at the current cursor position that allows you to rapidly click on common operations as well as customized shortcuts.

I have my own janky extension to quickdrop that makes a graphical menu present after pressing multiple buttons (ctrl+space, ctrl+q, then one of WASD or a mouse click on the popup .vi front panel), but it would be nice if I didn't have to go through multiple shortcut selections to hit my toolbar-of-target. Said another way, a more extensible quickdrop-like shortcut bar would be nice. Something like the right click and shortcut keypresses for Autodesk Fusion and Solidworks are the inspiration.

Integrating markdown, asciidoc, whatever. This would help eliminate a step for most of us lowly third parties making docs for our software. A built-in browser would be nice, or just opening the doc straight away in a compatible viewer would be fine.

Loading the NI website's page for the help doc takes ages. This could also be a way to locally host vi docs and have a built-in browser-like display of help files.

I frequently find the context help information not detailed enough and get frustrated waiting for the website to load. If it was a one-stop shop markup-based doc, that's meaningful time saved.

It's always a pleasure to uncover shared memory problems when working with base vi.lib methods that *should* work as preallocated clones and have uninitialized shift registers and then having to establish a chain of vi references to safely call those methods in an application with distributed/parallel threads. It feels like extra work but does fix the problem. It's a major unknown gotcha unless you're already familiar with the vi you are calling.

My most recent hiccup: the NI PID library. I needed two closed loop controllers in actor framework, and was getting very strange timing, setpoint, process variable, and control output crossovers until I realized the stock .vi's had shared memory in the form of uninitialized shift registers (despite being in the context of a pre-allocated actor). Creating references of the vi's I needed and storing them in the actor at launch fixed the problem, but at that point the effort in writing my own PID .vi starts to be a favorable time tradeoff. At least I am able to peek under the hood of the PID library, other aspects of vi.lib... not so much.

Or maybe this is a teaching problem. I haven't come across ways of navigating this issue from official NI documentation, in fact the way I learned I needed to call the PID.vi by-reference was from the forum and rather matter-of-factly. There are a couple of great blogs that cover this issue in detail, so I don't feel alone in my ignorance. Maintaining State Information in LabVIEW Applications, Part 5 - LabVIEW Field Journal Archives | LabVIEW Field Journal Archives

I like compile time type safety checks. I dislike using variants. Occasionally, and increasingly more often, I find myself going to great lengths to provide compile time type safety. At a point, the type check gets lost in the inheritance hierarchy and I am back to depending on runtime checks for errors. It's not uncommon for me to have a class method that needs to "just work" across the bulk of the base types, but it sure is a pain to make wrapper classes, static inlined methods, and a nasty polymorphic .vi to mimic this behavior. Perhaps I am ignorant to some features of LV (do malleable vi's fit in here somewhere?), but multiple dispatch/function overloading sure seems like the silver bullet for this issue without messy inheritance trees.

I'm open to discussion on alternatives. This "problem" has come up in a couple of recent projects of mine, and I always feel dirty using a variant or making a static API for a class that ought to be extensible.

LabVIEW Idea Exchange

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

Add support for Absolute Paths to LabVIEW Projects

pre-launch hash checker

Make Channel Wires Compatible with Diagram Disable Structure

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

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

Support "Development Environments" / "Development Sand Boxes"

fused multiply-add(FMA) for LabVIEW ?

LabVIEW native dataframe type

Class controls and indicators shall default to "this" class

Default Setting for "LabVIEW Version" in the Environment

Front Panel Control Context Help: Show Control Type

Graphical context menu at mouse pointer, super-duper quick drop

Extensible markup supported in VI documentation and help files. Locally hosting vi.lib help docs.

Eliminate uninitialized shift registers from vi.lib

Multiple dispatch / Function overloading