From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

Post an idea

When wiring to a growable node that is currently full requires you to either pull the node bigger first and then wire or wire and create a wire stub, then pull it larger and the Connect the stub to the terminal.

Instead change the behavior so, if wiring is started and ends over a growable node, the node will grow automatically and add the wire being created to the new terminal.

For example: starting an error wire and ending on a merge that is currently full, the node automagically grows by one and adds the wire to the new (last) terminal.

View All (2)

Provide a method to delete a shortcut to a recent file that is no longer current. The main LabVIEW window on the right-hand side below Open Existing has a list for All Recent Files, Recent Projects, Recent VIs, or Other Recent Files. The All Recent Files is default and perhaps most convenient. However, it always lists projects before files. Therefore, if we open numerous projects the recent files are pushed down and must be scrolled to, limiting convenience. It is common to open an example project, a new Untitled Project 1.lvproj, or one to help a coworker. These take up space which could show frequently-used files. These can be deleted from the LabVIEW.ini (e.g. RecentFiles.projectPathList, RecentFiles.pathList keys) but doing so it tedious and prone to allow accidental changes. A right-click pop-up menu could contain a Delete/Remove from List item; the Delete key cannot be used because there is no item selection since a single click opens the item.

View All (1)

I use Error Rings for custom errors and I love it. Being able to reuse existing codes but give addition information, or using extra string or numeric inputs makes my code more compact and readable. But one thing I noticed is that if I perform a search in LabVIEW, it won't look at the text in the Error Ring. Here is an example.

Error Ring Search 1.PNG

Even though my Error Ring contains the text "table" and it is even shown in the node, the LabVIEW search returns nothing. There are times that my users get an error and they send it to me. Then I will search for that text in my project only to find it isn't there. But it is actually there, just hidden away inside the XNode that is the Error Ring.

Can we improve the LabVIEW search function to search inside Error Rings?

View All (3)

Use case:

I have multiple (sub)vi's open or in memory with "Retain Wire Values" enabled, because I don't know in advance which wires I need to probe.

Initial State:
If I probe any wire now, they will all show "Not Executed".

First Execution:

After I have run my code, these (sub)vi's will show their values as promised and the parts of the code that have not been executed will display "Not Executed".

Now I have learned from my first execution and I made some changes in my code.

Second Execution:

If I would run for the second time now, I'll expect that my code will behave differently. This can mean that some code that did run in the First Execution did not run in the Second Execution and therefore would retain the wire values from the first run. In such a case I am not able to tell if a wire value is from the Second Run or from a First Run and actually "Not Executed" in the Second Run.

Normally, I will Disable and then Enable the "Retain Wire Values" option to clear the wire values, but this can be quite a hustle if you have a lot of vi's with this function enabled.

My wish:

I would like to have some kind of "Clear all retained wires" button or something that put all my vi's in memory with "Retain Wire Values" enabled in the Inital State, so they will all show "Not Executed" when probed.

This seems a simple and effective solution to me.

View All (1)

If you have an event that contains a cluster typedef, then the event structure automatically unbundles the data:

I generally want to work with the entire typdef though. Why not expose the entire typdef to improve code maintainability?

(No one wants to re-bundle that data just to send it to a subVI or new event...and then risk losing data when a new property is added later. Workarounds include adding a typdef of a typdef, or going class-based...but that overhead/creativity shouldn't be necessary.)

First of all I know this may sound crazy, but I do have a specific use case (2 actually) and I think it generalizes well.

Use Case

Caraya uses a Quickdrop shortcut ctl+u to run all unit tests in your project. I have a quickdrop shortcut that I use to run VI Analyzer on just the files that have changed in Git.

Both of these shortcuts are incredibly useful. However it requires having a VI open. There are often times when I just have a project open and want to use one of these shortcuts. For example when I first open a project, I often want to run the tests first thing. I realize you can add these type of things to the tools menu, but then I have to memorize 2 different ways of doing something depending on context. It would be much easier to use the QD shortcut here.

I realize that QD is typically used for dropping objects (on the bd and fp) and that doesn't really make sense from the project. But these shortcuts (and I'm sure there are others) don't rely on that functionality. Also you could adapt QD to act on highlighted project items or allow you to "drop" a new VI or class or library or something.

I mentioned it to Darren and he mentioned it would require the C code changes to allow the project window to capture the ctl + space event. The project window already does handle some ctl key events. Apparently ctl + space seems to be unhandled. I'm sure there is probably more to this idea than simply that, but I feel like it is worth exploring.

Right now Index a row / col from a 2D array is possible outside In-Place Element - as shown in Picture 1

Index-Replace 1D Array.JPG

But only one element index / replace is possible at a time inside In-Place element - as shown in Picture 2

Index-Replace In-Place.JPG

So it would be good if it is possible to index a row / col of a 2D array from inside the In-Place element structure. Only row index / col index could be allowed to wire without giving broken arrow. So one full row / col elements can be accessed and handled for any task.

Download All

Provide a way to save and recall sets of probes for a running application. A developer could then provide sets of various probes that would help the end user. The superprobe would remember the VI paths and locations in the block diagrams of the application's SubVIs and automatically load VIs from disk or monitor existing re-entrant copies in memory. The superprobe would have a front panel layout, like a global VI, to look like a custom dashboard of important data values in the applicaton.