LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

String controls, indicators, and constants support alternate display styles, which is extremely helpful. It would be really nice if this same capability (the ability to specify string values using '\' codes or hex display styles) were added to individual cases in the Case structure because it currently only supports the normal display style. I can't really think of a situation where it would provide any benefit for the Case structure to support the password display style so it could probably be omitted.

View All (1)

To keep LabVIEW competitive and easy to use with modern control systems and industrial applications, NI should provide first-class, out-of-the-box support for the most important communication protocols and data formats.Key protocols that need better support:

OPC UA – Continued and more extensive support is critical. The current toolkit has been threatened with discontinuation multiple times, and the required deployment license adds significant administrative overhead, making it less convenient than it should be.
MQTT with Sparkplug B – Several third-party MQTT libraries exist for LabVIEW, but none (to my knowledge) support Sparkplug B, which is frequently required in industrial IoT projects.
Modbus – Basic support already exists (good), but secure/encrypted versions will likely become the norm, especially with regulations such as the EU Cyber Resilience Act (CRA). Many customers who do not standardize on OPC UA may expect secure Modbus.

Other industrial standards would also benefit from native or easily available support.Broader recommendation – change in philosophy:The most popular protocols and data-handling capabilities should be:

Easily available (preferably included out of the box)
Free of deployment licenses (or with a much simpler licensing model)

The same gap exists in data logging and related areas:

HDF5 support
Database I/O
Compression and encryption

These should not rely on third-party implementations that often lack Linux Real-Time support or long-term maintenance.Making these capabilities first-class citizens in LabVIEW would significantly reduce friction for developers, improve cross-platform consistency (especially Linux RT), and help secure long-term interest in the platform.

If you use enums, rings, and combo boxes in LabVIEW, you may deal with a large number of items and associated values contained within them. It would be really nice if their property pages allowed you to sort, import, and export items and associated values (where applicable). It isn't a big deal to enter and modify items and values if their quantity is small. However, it can be tedious if you are dealing with large amounts of items and values. Importing and exporting values to and from text editors (e.g. Notepad), spreadsheet programs (e.g. Microsoft Excel), and/or the operating system clipboard, would allow quick creation and modification of long lists of items and values. A loose depiction of such capabilities is shown in the following picture and could obviously be implemented in different ways.

View All (4)

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)

View All (1)

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)

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

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)

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)

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)

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)

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)

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)

Inheritable Class Probes

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.

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.

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)

Remove unconnected on Index array

View All (2)

LabVIEW Idea Exchange

Add support for alternate string display styles to Case structure

Improved out-of-the-box support for key industrial protocols and data formats

Add the ability to sort, import, and export enum, ring, and combo box items and values through property pages.

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

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

Wire labels - add default properties to the Block Diagram Options

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

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

Improvements to Open, Save, and Other Path Selection Dialogs

Open-Source LabVIEW Benchmark Suite

Increase observability: Make LLVM output available for inspection

Add default value input to "Remove From Map"

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

Performance improvement: More native VIs should be set to subroutine

Improve right-click menu consistency for structures

Inheritable Class Probes

Add "Run N Times" Option to the LabVIEW Toolbar

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

Keyboard shortcut to enable Diagram Disable Structure case

Remove unconnected on Index array