LabVIEW Idea Exchange

Post an idea

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).

Currently, when you right-click -> "Make Type Def" on a control / constant in a library VI, the new unnamed type definition is created outside

the library.

Also, it has the default control icon:

instead of a library control icon:

This leads to 3 additional tasks:

1. Drag and drop the control inside the library from the project explorer.

2. Edit the control icon to make it have the library control icon (with the horizontal slider glyph).

This is annoying because you need to copy it from another library control icon.

3. Go to the library properties and make "Apply Icon To VIs".

Bonus bug: If your new type contains a library-private subtype, the new control magically disappears from the project explorer when you click on it.

In comparison, the "Create SubVI" function works perfectly inside a library, i.e. it creates a VI inside the library and with the icon banner.

I think the "Make Type Def" function should behave the same to make library development more coherent and intuitive.

View All (2)

View All (1)

Current behavior:

When saving a new .lvlib inside a .lvproj the save file dialog brings me to the last saved location which is often a different repo.

Desired behavior:

When saving a new .lvlib inside a .lvproj bring me to the root directory where the .lvproj is saved and not the last saved file location. i.e. implement the same behavior as when saving a VI inside a library or a class. This would solve the issue of VIs accidentally being miss-saved outside of the project folder and then getting lost.

View All (1)

Often when I want to look at the structure of a complex data type containing nested typedefs, I find the data type description in the Context Help quite heavy/verbose.

For example, could you tell at first glance how many levels of hierarchy there are in this data structure ?

Well, actually there are 5 levels (including the root cluster), but this is obfuscated by the unnecessary levels added by typedefs.

The description could be much more concise:

Here is an alternative that keeps the typedef type descriptions and appends them after the typedef name. However I'm not sure about this one because it could create description texts that are too long to be displayed in a single line:

Also for the configuration, it could be an option in "Options > Environment" and/or a button in the Context Help:

What are your thoughts ?

Raphaël.

View All (3)

Currently, if a new version of LabVIEW comes out with new shortcut menu plugin or a quick drop shortcut, that is written in LabVIEW the only way to have that added for older, still supported versions is to save them to for the oldest version, and copy them to the respective folders.

I wish, that the new features in these categories would be available trough download for the supported LabVIEW versions for everyone that has a license.

I would love, if these were separated into their own package, that is a dependency of the LabVIEW installer, but could be updated later from the package manager.

View All (3)

The current register event callback node is allowing an easy way to handle ActiveX and .Net Framework events. This node is also very similar in appearance to the property nodes, yet it does not have an insert (Add Element) or remove (Remove Element) function available in the context menu. Since the property nodes, and also the named (un)bundle nodes are having this implemented, I think it would be nice to have these easy to access functions instead or having to grow the node, change all the elements below the one that we want to insert and rewire everything.

One downside of this idea is, that it will throw the wires a little further away than the upper mentioned named (un)bundle and property nodes do, since it is a 3 terminal height element.

View All (4)

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.

<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"
}]

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 - https://jsonformatter.org/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"}]}

View All (4)

It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.

It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.

1 (edited).png

I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.

When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.

This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.

This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.

Thanks

View All (2)

I wish LabVIEW had Official Container (Docker) Images.

With more and more users trying to use the docker in Continuous Integration, it would be

interesting supporting a NI Official Image on Docker Hub (or any other place). Containers provide an easy way of creating reproducible tests and builds.

The build of LabVIEW docker images has been feasible since NI Package Manager command line was launched, and for NI wouldn't be a new thing.

The advantage is that the images (Windows, Linux or Mac OS) could be optimized by NI team only for working for LabVIEW, shrinking size and removing unused files.

Anyone else would support this idea or has anything to complement?

In common, the loops are divided into two categories: entry control loops and exit control loops. The entry control loop checks the condition first, and the code will get executed only if the condition is true. But in the exit control loop, the code will get executed first, and then the condition is checked.

So the "for loop" and "while loop" are entry control loops that will not execute the code if the condition is false, but the "do while loop" will execute the code (run) one time even if the condition is false because it is an exit control loop.

This is also the case in Labview, where the while loop will execute the code (run) one time even if we wire true to the conditional terminal, but in the for loop, if we wire 0 to the count terminal code inside the loop, it never gets executed.

So it is more meaningful to say the labview's "while loop" as "do while loop". Screenshot 2024-01-05 110311.png Screenshot 2024-01-05 110320.png

I have wasted ~~days~~ weeks of my life tracking down why dependencies are loaded in LabVIEW.

This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.

In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.

It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.

A malleable VI on a block diagram can be converted from an Instance VI to a Standard VI, which I've found useful to aid debugging. Unfortunately this modifies the calling code and requires the changes to be reverted to restore the original malleable VI.

This idea is to provide an additional right-click option for malleable VIs - View Instance VI. This would open the instance VI in memory, and allow read-only viewing of the block diagram.

This is useful when examining how the Type Specialization Structure cases are being evaluated given the currently wired inputs to a malleable VI. It also offers ability to quickly view the instance VI data types, helping determine which malleable input wires are *actually* broken. In the example below LabVIEW shows all of the inputs to Stall Data Flow.vim as broken, though viewing the instance VI shows only one input is actually broken.

When the Instance VI is opened for viewing, it wouldn't offer any runtime debugging, but means no changes need to be made to the calling VI when performing static code analysis at edit time.

The ability to view instance VIs already exists in LabVIEW through VI scripting (see example below), but would be nicer to have quick access to it when right-clicking a malleable VI.

View All (2)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

Give me a “modal when called” Front Panel / Window behavior or I will Kill LabVIEW (taskkill /f /im LabVIEW.exe)

Include foolproof shortcut to stop all running VIs and report which VIs were shut down

Type Def made inside a library VI should be part of the library

Quick Drop Replace Terminal

Default to .lvproj folder root when saving new .lvlibs in a project

Option for compact data type description in Context Help

Increase Icon Resolution

Make the new shortcut menu and quick drop plugins available trough download for older versions

Drop-downs for Selecting Conditional Disable Structure Options

Allow inserting and removing event handlers in the Register Event Callback node context menu

Retain all errors option of Merge Errors.vi does not output a valid JSON string

Support for Timed Loop/structures on Desktop Linux

"Always On Top" option for Search Results window

Official LabVIEW Docker Images

Cluster Support for "Add Array Elements"

Change the "while loop" name to "do while".

Make QuickDrop Quick

"Why is this item in Dependencies" should only show items that are directly dependent on it

LVCompare for Classes and Libraries

Malleable VI - Option to view Instance VI