LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Problem

I would like to create HTML report of my unit tests run together with information about project code coverage. This can be achieved if the "Generate HTML report" option is checked in Project>>Properties>>Unit Test Framework and when the tests are run via toolbar operation "Run Unit Tests". However, I want to create same HTML report with PROJECT CODE COVERAGE programmatically via "Create Report.VI" or CLI, but the report generated in this way doesn't contain the code coverage information.

Run via Create Report.vi

bender_robotics_4-1760687909082.png

Run via toolbar

bender_robotics_3-1760687866751.png

Why This Matters

This functionality can be useful for running unit tests and report creating via custom CLI operation for CI. My scenario is to use the report as an CI artifact with informative value about code coverage.

It would be nice if the format to string would support arrays.
Something like this:

MikaelH_0-1760513019416.png

 



It is necessary for porting code that uses nextafter() in C or Python(or other languages) to LabVIEW.

Make Nigel AI advisor able to analyze changes within git repo and suggest a commit message.

 

This would be useful to : 

  • Make commit messages more relevant / use message conventions
  • Avoid undesired changes
  • Avoid undocumented changes

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.

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:

raphschru_1-1759327735617.png

 

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

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).

 

I'm not sure if someone has requested it yet, but it would be very helpful if I could clear the probe watch window of the last retained values. This way I don't need to look at the timestamps and it will speed up the debugging.

En un mundo cambiante tecnológicamente, se requiere responder antes los nuevos retos tecnológicos y, en materia en intercomunicación de apps, estaría excelente contar con herramientas, (API, TOOLKIT etc.), fáciles de usar como se ha caracterizado LabVIEW, para poder comunicar y enviar la información que se genera por medio de LabVIEW a otros sistemas como SAP S4HANA ON Cloud, actualmente tenemos SAP S4HANA ON PREMISE y esta excelente, sin embargo, todo cambia y en algunos casos se vuelve un desafío el poder cambiar con transparencia y facilidad, estoy seguro que es posible desarrollar diversas herramientas que pueda compartir la información que se genera desde el hardware de NI, a cualquier otra plataforma que los diversos clientes requieran, en nube, dispositivos móviles etc.

Similar to a Static VI Reference, you could have a static file reference which would function just like a path but would allow non-VI files such as a script to be called by a sysexec call or a python node, etc. to be implicitly included in a build without having to remember to add them as "always included".

It would be nice to have a performant way to execute an abstract represented VI.

There are currently two generic ways to execute a VI by reference:

- abstract represented but not performant (FP required, running in UI threading)

- specific represented and performant

Executing a VI currently.png

Is it possible to provide such a functionality which combines the advantages of both solutions like this?

Executing a VI proposed.png

This means, the target VI could be handled in abstract way without coupling to the specific VI connector panel.

It would be nice to get 64bit references. The old 32bit references are build up from two main parts: the descriptor represented on 12bits and the address represented on 20bits. If the application requires more than the available 1048576 references the labview generates an error because the memory is full. The workaround is to close references found in the memory. If an application requires serialization, this rule should be kept in mind. If the application serializes references by an input data, the input data should be limited, which means that really big data can't be handled although the machine have enough memory to handle them. Unfortunately, this feature in the labview has been not changed in the last 30 years although 64bit processor architectures are used world-wide and the 64bit labview plays a bigger role every year.
I think, the main reason is the backward compatibility...but is it possible to provide 64bit references which could be chosen by the developer itself, where the descriptor field will not be changed but additional 32bits are available for addressing? e.g. new option in the labview settings "use 64bit references" or selection (polymorphic) from all native components which could be create a reference. If the feature is supported by (environment) settings, then the compiler uses it generic. If the feature is supported component level, then the references should be checked for conflicts. At the end the architect/developer/application is no more limited inside in the labview because the available 4503599627370496 addresses are more than enough for a long time again.

It would be nice to have a managed solution to get LV Class properties both in development and in runtime environment: name of the properties, concerning accessor VIs with path and scope information.

Currently the only way to get these information is to handle the classes by XML parsing methods. This is neither managed solution nor working for classes which are found in compiled codes.

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.

 

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.

 

bhpowell_0-1756585981792.png

 

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:

bhpowell_1-1756586494123.png

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.

Bookmark Manager is very useful but it can be hard to find what I want when I have a lot of bookmarks. So I would like to add a filter function.

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.