LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (4)

Hi,

I'm submitting 2 feature requests with this post - both about helpful features for Case Structures that would make my team's work with debugging, sustaining, and building QMH architected programs easier and faster. While this initial request is specifically for Case Structures, the same principles and ideas apply to Event Structures as well.

Feature Request 1: Ability to Jump To Last Viewed Case(s)

My company works on a lot of projects where there are dozens of cases used in the QMH consumer loop which sometimes enqueue 1-to-N number of other cases in the same Case Structure.

In the following example, "Case 1" enqueues "Case 2", "Case 3", and then "Update 4". If I want to debug to investigate the sequential order of events, I will need to go and find those cases manually from the dropdown.

Again in this example, in the image below you will see that when I get to the case "Update 4", then three more cases are enqueued, so I'll have to do even more navigation through the Case Structure to understand the full sequence of what happened.

Now, let's review the sequential order of cases enqueued thus far: "Case 1" --> "Case 2" --> "Case 3" --> "Update 4" --> "Test 1" --> "Test 2" --> "Test 3".

If I want to quickly retrace my steps, I run into a couple different issues. 1) I have to rely on my memory for the execution order and 2) I have to manually reselect each case through the case dropdown list, which is slow - and even more slow if there are dozens of cases.

It would be very helpful to have a keyboard shortcut (or exposable block diagram object) that would allow you to Go-To the most recently viewed case(s), much like how CTRL+Tab allows you to tab through your most recently viewed LabVIEW windows. I suggest CTRL+Shift+T, largely due to the fact that my name is Tommy.

Feature Request 2: Ability to Search for a Case (String-case selector only)

Some QMH programs that we help develop (or that we inherit) have up to a hundred cases in the Case Structure. Finding the case you want, especially if it's at the bottom of the list and you have to use the slow auto-scrolling arrow feature, is very slow and inefficient.

Having some exposable block diagram object that would allow you to filter your search - for string-based Case Structures - would be very helpful. Perhaps you could expose/unexpose from the "Visible Items" property which would provide a String Text Box on the upper border of the Case Structure that could be used as the String filter. If the Case Structure is being filtered, then there would be some color indication (perhaps on the entire border?) that would indicate that the list is currently filtered and not showing the whole list.

Thanks and would love to hear any feedback on these idea, or if any feature like these have already been included in LabVIEW and I am just unaware of them.

Best,

Tommy McCoy

I've had a chance to use the UTF-8 support in LabVIEW 2026 Q3, and for the most part I love it.

This post documents one of just a handful of headaches I've encountered with it.

Since a given character in UTF-8 has a variable number of bytes depending on its numeric value, it's a bit involved to convert between the number of bytes a string occupies and the number of characters represented.

For example, often you want to know the length of a string in characters rather than its length in bytes.

There are some functions that could benefit from having the ability to toggle "character count" mode, vs. "byte count" mode. Namely:

String Length
String Subset
Replace Substring
Search and Replace String
Match Pattern (Except it doesn't work with UTF-8 yet)
Match Regular Expression
Search/Split String

There are probably a couple of additional ones I left out.

For these functions, would it be possible to add a context menu selection, "Character Count", that the user may use to toggle off character count mode?

This is what I envision the option might look like for the String Length node. Note the "abc" visual cue on the function connected to the "Chars" terminal. The Character Count menu item would have a check mark leading the text if Character Count were enabled.

In my first project using it to localize UIs, I had to "roll my own" VIs that work with UTF-8 strings in character counts. For length, I check bits 3-7 of the first byte of a char to determine how many bytes represent it.

Thanks very much,

Jim

Recognition is in order: A huge thanks to NI's developers who finally implemented the UTF-8 support.

I think there was serious discussion about how it would be implemented only two years ago (or was it last year?) at GDevCon NA.

It was a very quick turnaround considering how much had to be done to support it, especially in all of the myriad properties and methods of controls.

For the most part, everything just works, and I wrote my first UI with true natively supported translation.

View All (6)

I would like to revive an idea proposed by matt.baker in January 2017. The idea was declined because it received less than 3 kudos in 3 years.

Specifically, it would be great if LabVIEW programmers were able to view the Dataflow Intermediate Representation (DFIR) of a VI.

For clarity, I am asking for the ability to strictly view the DFIR, not to edit or alter it. Simply viewing the DFIR in a window, perhaps with the ability to save the DFIR diagram as a PNG or PDF file.

For those who might not know, please note that internally NI has long had the ability to view the DFIR of any VI. This idea asks to essentially share the internal viewing tool (or a slimmer, less-fully-featured version of the internal viewing tool) with the LabVIEW community.

Viewing the DFIR would be useful to programmers that:

Develop high-throughput, high-performance applications where achieving the highest possible performance is the goal.
Develop small, low-level reusable libraries, including free, open-source VIPM packages. These programmers could use the DFIR as a tool in their arsenal, helping them deliver reusable code with the best possible performance.
Are looking to understand the LabVIEW compiler better, to gain intuition into efficient vs. not-efficient LabVIEW coding constructs. An efficient coding construct is one that results in a lean DFIR.

Other programming languages expose their intermediary representations. For example, C# programmers can use tools such as the ILDASM (Intermediate Language DisAssembler) to inspect the .NET IL (Intermediate Language) produced by C#. Source: Intermediate Language (ILDASM & ILASM), Common Intermediate Language - Wikipedia.

Based on brief research (please correct me if I'm wrong), it seems that Java programmers have access to something similar, named the ability to inspect the Java Virtual Machine (JVM) bytecode. There is a useful quote in the JVM bytecode Wikipedia page: "Understanding bytecode and what bytecode is likely to be generated by a Java compiler helps the Java programmer in the same way that knowledge of assembly helps the C or C++ programmer." The LabVIEW DFIR would help LabVIEW programmers in the same way that this quote suggests.

Resources:

The NI LabVIEW Compiler: Under the Hood article introduces DFIR.
The LabVIEW Compiler Under the Hood.pptx attached to this forum post provides more details.

The following is an example DFIR diagram presented in slide 24 of the pptx.

DFIR Example From PPTX.png

Counter-arguments

In a reply to the original idea, AristosQueue mentions that "This is not something we are going to be productizing." and highlights that DFIR diagrams can be large and complex even for simple VIs.

While I fully agree and understand that DFIR diagrams may be complex even for simple VIs, comparing DFIRs from one version of a VI with another could still be a fruitful exercise that helps identify optimisations. For example, let's say the DFIR of A.vi is viewed and saved as a PNG file. The programmer then refactors A.vi while maintaining identical functional behaviour. The programmer then views the new DFIR and visually compares with the initial DFIR (the PNG file). If the DFIR is visually much simpler than before (much fewer graph nodes and connections), there's a good chance that the VI will execute more quickly.

In other words, I fully agree with AristosQueue's thoughts that inspecting, understanding, comparing DFIRs may be a time-consuming activity, and activity that only a small subset of programmers may be interested in. Nevertheless, viewing DFIRs would be valuable to experienced programmers who are looking to understand the compiler better, and to produce more efficient code, sometimes for the benefit of the whole community (reusable VIPM packages).

In general, anything that increases the observability of LabVIEW is welcome, as it enables us (professional LabVIEW programmers) to make better decisions.

View All (1)

In the last few years, NI correctly and for the benefit of the LabVIEW community open-sourced a large number of repositories. For example, the LabVIEW Icon Editor and the Actor Framework. This is extremely useful and appreciated.

This idea asks for NI to open-source some or all of the benchmarks that NI use internally for evaluating the LabVIEW compiler and how the compiler improves from version to version.

Slide 20 of the excellent LabVIEW Compiler Under the Hood.pptx attached to this forum post (a slide deck published by NI) contains the following diagram.

LabVIEW 2010 Performance Metrics (Slide 20).png

The slide notes are "Here we see the results of our investment in the compiler and the performance of code. Our benchmark suite included an exhaustive set of tests and computational tasks, well beyond what you see here, but it’s important to note that the execution speed was overwhelmingly faster. Nothing was slower, and on average, we expect roughly a 20% performance increase.".

Note the use of "our benchmark suite" - this strongly suggests that NI has an internal benchmarking suite.

In the diagram, note titles such as Complex Math - Black-Scholes PDE solver, Real-time Math (PXI-8196) - MathScript Heat Equation, Parallel For Loop - Mandelbrot, and Large Array Math - Linear Scale (Multiply and Add) - these are likely the names of individual VIs or groups of VIs that are part of the benchmarking suite.

Having access to a standard set of benchmarks would help LabVIEW programmers in various ways, for example to evaluate how much faster a machine is compared to another machine at executing a particular LabVIEW task or a group of more general LabVIEW tasks. The benchmark suite being open-source would enable programmers to expand the suite and contribute new benchmark VIs.

LabVIEW Champions Forum

NI community members that have access to the private LabVIEW Champions Forum can find a post titled "Is there a general benchmarking suite available?" posted by user swatts (Steve Watts) on 08 April 2024. In that post Steve asks if a general benchmarking suite is available. None of the replies provide a link to such a benchmarking suite - this indicates that such a suite is not published yet. I copy below a screenshot of my reply to that topic - in this reply I highlight several use cases where a benchmarking suite would be useful.

Arguments in favour of a benchmarking suite.png

View All (3)

Hey there. When you open, save, or otherwise select a file or directory from a dialog, there are a couple of behaviors that LabVIEW sometimes exhibits that I find very tedious:

LabVIEW forgets with path you last selected in a given use case, so you have to repeatedly select the same file or directory over and over
LabVIEW recalls the last used directory, but that directory isn't specific to the context of what you're doing.

An example of the first annoyance is the Mass Compile dialog. If you want to mass compile adjacent directories that aren't anywhere near your last opened path, you have to go all the way back to that directory again.

I ran into the second annoyance yesterday. I was constantly browsing for VIs and controls in a different directory than my project hierarchy, but also concurrently browsing for .NET Core assemblies in Program Files\dotnet

Repeatedly going back and forth between my project hierarchy and the .NET assembly directory became very, very tedious in short order.

LabVIEW recalled the last directory I'd opened, but it made no distinction between the context of the use case.

This is kind of along the lines of Rolf's post many years ago:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-the-file-dialog-default-path-when-saving-new-files/idi-p/1725842#M14728

Another idea somewhere in the Exchange was to have a list of recent paths in the dialog the way TestStand implements the feature. In my opinion, that is probably the easiest implementation that would solve both of the grievances I mentioned.

Thanks for your consideration.

Jim

View All (5)

I would like to revive an idea proposed by matt.baker in January 2017. The idea was declined because it received less than 3 kudos in 3 years.

Specifically, it would be great if LabVIEW programmers were able to inspect the LLVM Intermediate Representation (IR) associated with a VI and/or an EXE. As one possible implementation, LabVIEW could output the LLVM IR associated with a VI to a text file (perhaps saved with the .ll file extension, which seems to be the usual extension for LLVM IR text representation).

If LabVIEW made the LLVM IR available for inspection, LabVIEW programmers could then use existing, non-NI tools to better understand how the LabVIEW compiler works and how to achieve the best possible performance in their LabVIEW applications and/or reuse libraries.

Existing LLVM IR inspection tools include:

travitch/llvm-tools: A set of tools for visualizing and inspecting LLVM bitcode modules. "This package includes some tools to visualize the LLVM IR. Current visualizations include static call graphs, CFGs, CDGs, dominator trees, and some simple escape graphs. Output formats include most graphviz-supported formats, along with an HTML-based format."
LLVM Tools – Essential Utilities for IR, Analysis, and Optimization | CompilerSutra

Commonly Used LLVM Tools.png

The ethos of this idea - increasing observability of compilation artefacts to enable LabVIEW programmers to make better decisions - is identical to that of an idea posted earlier today: Increase observability: Ability to view Dataflow Intermediate Representation (DFIR). I posted the two ideas separately because, while their end-goal is identical (more observability), they can be implemented independently of each other.

The following diagram explains the LabVIEW compilation process (i.e. the transformations that transform a block diagram into machine code). This diagram originates in slide 19 of the excellent LabVIEW Compiler Under the Hood.pptx attached to this forum post. I annotated the diagram by adding the blue text.

Slide 19 Diagram (edited).png

Idea Implementation

I don't know it for a fact, but it's likely that internally NI have extensive tools and techniques for analysing the LLVM output of the LabVIEW compiler. What this idea requests is for some of these tools (perhaps in a lite, less-fully-featured version) be shared with the rest of the LabVIEW community.

Resources

The NI LabVIEW Compiler: Under the Hood article introduces the role of LLVM in the LabVIEW compilation process.
The aforementioned pptx provides more details.

View All (2)

Many native VIs currently use normal priority when they should be using subroutine priority. These are small, low-level VIs that contain small amounts of code. These are perfect candidates for using subroutine priority.

In other words, more native VIs should use the following execution settings.

More Native VIs Should Use These Execution Settings.png

Native VIs = VIs that ship with LabVIEW. Most native VIs are located in the vi.lib folder.

Details

This LabVIEW User Manual page states “Select subroutine priority to make the LabVIEW execution system run the VI as efficiently as possible." Through my own benchmarks I was able to confirm that the manual is correct (as expected): the same Preallocated Clone Reentrant subVIs execute more quickly when their priority is set to subroutine compared to when their priority is set to normal.

The following screenshot shows a list of small, low-level VIs that ship with LabVIEW that would benefit from being set to subroutine.

Table of native VIs that would benefit from being set to subroutine.png

This list is just a start. It isn't exhaustive by any means. It was based on spending around 30 minutes inspecting native VIs. I'm sure many more VIs-suitable-for-subroutine could be identified by spending more time and inspecting more VIs.

The VIs listed above are found in the Mathematics >> Linear Algebra >> Basic Linear Algebra Subroutines palette, or are non-palette subVIs of VIs in that palette.

Basic Linear Algebra Subroutines Palette.png

As an example of the types of VIs we are talking about, the screenshot below shows the front panel and block diagrams of Diag Convertor.vi and Side Convertor.vi. Notice how small and "pure" (i.e. have no side-effects) these VIs are - these are exactly the type of VIs that should be set to subroutine.

The nature of Diag Convertor and Side Convertor.png

Benefits of more native VIs being set to subroutine

LabVIEW applications would become more computationally efficient when run in both Development Environment and EXE. There is a certain computational overhead when a caller VI calls a subVI whose priority is set to normal. That overhead is removed when the subVI is set to subroutine priority. What this means in practice is that many real-world LabVIEW applications would get a little bit faster (more computationally performant), because the calls those apps make to native VIs will have been optimised.
LabVIEW programmers would be able to set more of the VIs created by themselves (non-native VIs) to subroutine. A VI can be set to subroutine only if all its subVIs are also set to subroutine. This means that, currently, a programmer may be prevented from setting their own suitable VIs to subroutine because the programmer's VIs call native VIs that are not yet set to subroutine.

Subroutine vs. Inline

Please note that setting VIs to inline increases their performance even further compared to subroutine. In other words, using "inline" achieves even better performance than using subroutine. Some VIs, for example the two shown in the two screenshots below, are set to both subroutine and inline.

Positive exampels - Table of native VIs that are already correctly set to subroutine.png

Positive examples - Native VIs that are already configured for maximum performance.png

On one hand this is positive - it shows that the creators of these VIs kindly paid attention to configuring the VIs towards achieving maximum performance. On the other hand, using too many inline VIs slows down the editor (makes the IDE react sluggishly when creating or deleting wires). Using the inline setting brings a trade-off between achieving the best possible execution performance and slowing down the IDE.

View All (1)

I have been working with lots of Diagram Disable Structures lately. Specifically, I have been using Diagram Disable Structures to performance-benchmark various implementations that are functionally equivalent but whose execution time is different.

Currently the only way to enable a Diagram Disable Structure case is to right click the structure and select Enable This Subdiagram from a long right-click menu. This works but is quite slow. I sometimes have to spend more than 1 or 2 seconds to find the option and click on it. This adds up when performing the action dozens or even hundreds of times per day.

Having a native keyboard shortcut that performs this action would increase productivity.

Keyboard shortcut to enable Diagram Disable Structure case.png

View All (2)

Currently, LabVIEW allows a VI to run once or continuously, but not a specific number of times. Adding a numeric field beside the Run button would let users define how many times a VI should execute. The VI would automatically stop after completing the selected number of iterations. This would simplify testing, debugging, and validation without requiring temporary loop counters in the block diagram. The feature would improve productivity while preserving the current behavior when no value is specified.

Inheritable Class Probes

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:

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)

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?

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.

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:

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:

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:

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)

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:

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

Remove unconnected on Index array

View All (2)

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.

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)

Reorder Array Primitive

If you need to reorder an array containing very large data elements it is difficult to achieve it in a speed and memory efficient way.

PinguX did a good job doing so in a malleable VI and the in-place structure in this thread, but the most efficient solution ended up being based on Rust...

So my suggestion would be that NI adds a Reorder Array primitive to LabVIEW that matches (or outperforms! 🙂 ) the Rust-based one. Perhaps it could even support more than 1 dimension. The inputs would just be any type of array and an array of indexes.

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)

LabVIEW Idea Exchange

In the Select VIs To Search window a Text box to filter files by name

Case Structures: 1) Add Ability to Jump To Last Viewed Case(s) and 2) Ability to Search for Case (string CS's only)

UTF-8: Add the Ability to Work in Character Counts Instead of Byte Counts

Increase observability: Ability to view Dataflow Intermediate Representation (DFIR)

Open-Source LabVIEW Benchmark Suite

Improvements to Open, Save, and Other Path Selection Dialogs

Increase observability: Make LLVM output available for inspection

Performance improvement: More native VIs should be set to subroutine

Keyboard shortcut to enable Diagram Disable Structure case

Add default value input to "Remove From Map"

Add "Run N Times" Option to the LabVIEW Toolbar

Inheritable Class Probes

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

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

Improve right-click menu consistency for structures

Officially Support and Improve Alpha in Picture Controls

Remove unconnected on Index array

Add option for combo box separator value

Reorder Array Primitive

LLM-controlled LabVIEW scripting layer