LabVIEW Idea Exchange

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

This topic keeps coming up randomly.  A LabVIEW class keeps a mutation history so that it can load older versions of the class.  But how often does this actually need to be done?  I have never needed it.  Many others I have talked with have never needed it.  But it often causes problems as projects and histories get large.  For reference: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes.  The history is also just added bloat to your files (lvclass and any built files that use the lvclass) for something most of us do not need and sometimes causes build errors.


My proposal is to add an option to the class properties to keep the mutation history.  It can be enabled by default to keep the current behavior.  But allowing me to uncheck this option and then never have to worry about clearing the history again would be well worth it.



The DAQmx apis allow streaming measurements to TDMS. This supports spanning multiple files (by setting the max file size for individual files in the span set), which is very useful.

We need a similar feature for files we're writing to directly (i.e. not using DAQmx) with the TDMS File functions in LabVIEW.



Note: The main reason we wanting this feature, right now, is that our files are growing quite large and when we run the TDMS Defragement function, we get out of memory errors in RT on cRIO (e.g. if we have 512MB RAM on our cRIO and the TDMS file is around the same size).



We're thinking to do this ourselves, however the TDMS file api does not support checking the file size from a TDMS file reference  (and that's a great idea, too).

I'm not totally sure how this would be added to the TDMS file api -- maybe there could be a "TDMS Advanced Spanning" palette with options for configuring and interacting with TDMS spanning.

Currently, the TDMS File api does not offer a way to get the TDMS file size.


Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too).  To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).





I like channel wires for obvious reasons. I like to have modules, which work on their own, coming with their own GUI. This is convenient for developing my modules and testing them. Afterwards I want to be free to insert this module into a bigger project, which takes control of my module.

The channel wire controls on the connector pane can be set optional, but LabVIEW throws an error, when executing a VI with not connected channel wire control. (All branches of a channel wire must be connected to a channel endpoint...)
Please make VIs working with not connected, optional channel wire controls on the connector pane. That way, we can have channel wire based modules, which can run on their own, as a single VI, or can be controlled remotely without any change.



The compare tool is fundamentally broken which is somewhat shocking considering that such a tool is essential to any sort of large scale or long term software development.


Attached is a basic LV 2023 example which illustrates some of the many flaws with the tool.  If you compare "old version" and "new version" vi without including cosmetic changes, the tool shows 33 differences, most of which are incorrect.


Timed Loops are only supported on Windows and RT, making it difficult to port applications that use it to Linux.


In talking to some NI R&D people, it should be possible to port the RT Linux shared library to desktop Linux. (Perhaps it wouldn't even need to be recompiled, since it's x86.) We also need support in the editor on Linux to allow us to drop the structure.


This seems like low-hanging fruit to at least try to implement.


When looking for unexpected behaviour in time or memory usage of a project the Profiler is useful and easier than the execution tracer, but it could be made much more useful by adding the ability to monitor for changes and analyse the issues.




Currently detecting how the memory or run counts e.g. of a VI changes over time you have to take snapshots, save them and then compare the values in e.g. Excel. (which the saved traces do not directly fit into either...)

Proposed feature: Trends
It would be nice if you could just set the tool to automatically sample and log all/selected numbers regularly and then be able to view the trends. 


Proposed feature: Automated Analysis
Having trends will help in manually detecting issues, but the profiler could also have tools that helped you in this, e.g. highlighting which VIs show a continous growth in memory. This could also then be expanded by being able to call a VI analyzer on any given VI - preferably made/set up to identify possible reasons for a memory leak e.g. (unclosed references, continous array building e.g.).

Current Behavior:

When using the "retain all errors" option of the Merge Errors function the combined error message JSON output is not a valid JSON string.

This is the source output of Merge Errors when retain all errors is active - it is not a valid JSON string.


    "status": true,
    "code": 111,
    "source": "This is a test message including\nnewlines"
    "status": true,
    "code": 222,
    "source": "This is a test message including\nnewlines"



Desired Behavior:

Make the combined errors source string a valid JSON string so that it can be parsed by other tools.

Valid JSON string:


[{"status":true,"code":111,"source":"This is a test message including\nnewlines"},{"status":true,"code":222,"source":"This is a test message including\nnewlines"}]


 The above JSON string can be formatted nicely by most tools - e.g. JSON pretty print -


The below string including the JSONErrorMultiple_1.0 key (but formatted correctly) also works:


{"<JSONErrorMultiple_1.0>":[{"status": true,"code": 111,"source": "This is a test message including\nnewlines"},{"status": true,"code": 222,"source": "This is a test message including\nnewlines"}]}



Using 2023 for the first time (skipped 2021 and 2022)


QuickDrop used to be quick.

It was very convenient.


Now it takes a second to load.


That's pretty inconvenient if you're trying to... do much of anything.


Best example: If you're trying to remove code (Quickdrop's Control-R), now instead of quickly removing the selected code, you get to deal with accidentally RUNNING your VI (Menu's Control-R)


Please make it Quick again

The recently introduced Raspberry Pi is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).


The Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 15 times the processing power!


Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?

Please implicitly consider array index during index / replace elements in In Place Elements Structure if I am starting from Index 0


Present method:


Expected method:
image (1).png


[admin edit 2021-02-24]: placed images in-line with text and removed them as attachments

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:




AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!


We need this:


 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.


 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

The Swap Values node only supports a Boolean input on the '?' terminal.


It should also support an error cluster input, in the same way as the Select node (pictured) and many other nodes with Boolean inputs.

LabVIEW crashes randomly when network functions are used on Linux. This problem appears especially when many connections or files are open.

R&D has identified the issue but is evaluating wheter or not the issue will be resolved in future releases.


All the details are here :


An example is attached.





Download All

There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂





As soon as we have more complicated data structures (e.g. clusters of arrays), a large portion of the FP real estate is wasted taken up by borders, frames and trims, etc.


We need a palette full of "Amish" 😉 controls, indicators, and containers that eliminate all that extra baggage. We have a few controls already in the classic palette, but this needs to be expanded to include all types of controls, including graphs, containers, etc.


A flat control consists of a plain square and some text (numerical value, string, ring, boolean text, etc). A flat container is a simple borderless container.  A flat graph is a simple line drawing that would look great on a b&w printer. A flat picture ring looks like the image alone.


They have a single area color and a single pixel outline, if both have the same color, the outline does not show. They can also be made transparent, of course. If we look at them in the control editor, there are only very few parts.


Now, why would that be useful?


Let's have a look a the data structure in the image. There is way too much fluff, distracting from the actual data. If we had flat objects, the same could look as the "table" below. Note that this is now the actual array of clusters, no formatting involved! It is fully operational, e.g. I can pick another enum value, uncheck the boolean, or enter data as in the cluster above.


Many years ago in LabVIEW 4, I actually made a borderless cluster container in the control editor and it looked fine, but it was difficult to use because it was nearly impossible the grab the right thing with the mouse at edit time.


The main problem of cours is that the object edges completely overlap, making targeted seletion with the mouse impossible. (For example the upper right corner pixel is the corner of an array, a cluster, another array, and an element at the same time.)


So what we need is a layer selection tool that allows us to pick what we want (similar to tools in graphics editing software). It could look similar to the context help shown in the picture with selection boxes for each line. Picking an object would show the relevant handles so we can intereact with the desired object. Another possibility would be to hover over the corner and hit a certain key to rotate trough all near elements until the right element is selected, showing it's resize handles. I am sure there are other solutions.


As a welcome side effect, redrawing such a FP is relatively cheap.


Message Edited by altenbach on 06-03-2009 09:20 AM
Message Edited by altenbach on 06-03-2009 09:20 AM

It would be nice to easily find objects that prevent a structure with "Auto Grow" from becoming smaller in size.  For example, the Add function in  the True case in the simplified example below.





Many of these VI properties are "Run-time" writeable.  They should not be set while the vi is in an "Idle" state 


Screenshot 2023-05-12 191049.png

I don't know how many times I've added a case statement post-programming, but I do know that there isn't an easy way to make a tunnel the case selector.  Usually I delete the tunnel and then drag the case selector down and then rewire, there should be an easier way.  For loops and while loops have an easy way to index/unindex or replace with shift register, why can't a case statement be the same?



Searched briefly but couldn't find any ideas about this.


I know we have the ability #via_ignore comments to ignore specific tests for a specific VI, but I am looking at a different use case.


Here's the use case, I use DQMH. When you create a new DQMH module there is a lot of plumbing code that comes with it. It's standard stuff. Very rarely do I have to open or edit it. Much of it is scripting generated. It often fails tests but I don't care. In addition to failing, it takes up test time, which slows my feedback loop. I would a way to signal to VI analyzer to skip these files. I know I can use the VIAN API to limit the files it checks, but I was thinking there had to be a better way. 


Implementation Ideas - I had 2 main ideas

- Regex matching on VI names - with the regex pulled out of a text file somewhere ala gitignore. Many of the DQMH generated VIs have standard names, so that is easy. When generating events, they don't but you could easily add a prefix/suffix or something that the regex would pick up.

- Using the Tag API to tag the VI. I like this because the scripting can just apply the tag or apply it to the template the scripter uses. Downside is: kind of hidden from the user and perhaps if I decide to make some edits to this VI  I may want VIAN to stop ignoring it and it's not immediately obvious how to do that.



I picked the Execution and Performance Label because it didn't seem to fit any of the labels easily. If this is the wrong label and you are an admin, please relabel it.