LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Problem: Currently, the native nodes and VIs that can be used for error manipulation are located in the Dialog & User Interface palette. While manipulating errors can mean generating dialogues, and can influence the User Interface/User Experience, error manipulation is a broader and stand-alone topic.

Solution: Nodes and VIs that are relevant to error handling/error manipulation should be given their own subpalette inside the Programming palette. The new subpalette could be named "Error Handling", "Error Manipulation" or "Errors".

1 (annotated).png

2 (annotated).png

View All (3)

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

2 Screenshot (AEH off).png

3 Screenshot (AEH on).png

Idea expansion:

Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

View All (2)

TL;DR: the idea is please make building as fast in new LabVIEWs post 2023 Q3 as old ones when you have a clear compiled object cache and when your file timestamps have changed.

LabVIEW 2023 Q3 includes a major change to the app builder:

LabVIEW 2023 Q3 has improved cache behavior for packed project libraries and applications.

The first build will populate the cache, and then the subsequent builds will be much faster.

Great! It is pretty easy to confirm this and it works! Unless...

1. File timestamps change - such as when you clean a directory and clone project files in your CI job

Git does not make file timestamps match "commit date" - when you clone fresh all the timestamps are now o'clock, when you change branches all the files that change are reset to now

2. The cache is cleared prior to the build - such as when you want a repeatable build unaffected by prior state so you set your CI jobs to clear it before each build

3. You are doing a "first build" on a new project - such as when you use a container or VM disk image to reset the entire environment to a clean state prior to your CI job

In all my testing, any of these conditions pretty strictly cause builds to be slower in LabVIEW 2023 Q3 than in earlier versions: with a clear cache by typically ~60%, with new timestamps and a persisted cache depends on how much of the code has new timestamps.

In other words, I expect most everyone using CI will find building slower in 2023 Q3+ than later versions. So, the idea is: whatever optimizations were done, include an option to revert to the old behavior - build spec, config ini, editor option, whatever.

The help page, that is supposed to provide a starting point for the developers on creating readable, high quality code in LabVIEW seems to be unchanged for quite some time: LabVIEW Style Checklist - NI.

At different workplaces (including NI) and different teams I have seen different implementations of such guides, many of which included extra "rules".

One such example is the file naming convention:

Using spaces for separating words.
Using Libraries to namespace VIs instead of including the noun in every related VI.

These are the most prominent examples I can come up with from the top of my head, but I'm sure that there are more.

I'm curious if an updated version exists somewhere that could be used to replace the above refenced help page?

If there is not, then I think could we collect some ideas here for updating this document.

View All (2)

More Colors for Classes

When you create a class, it gets assigned a "random" color. But there are only 6 (or so) colors that are randomly chosen from. I do a lot of LVOOP, and generate a lot of classes. But because there's such a small selection of colors, I'll often drop class methods with the same color banner next to each other (and yes, with text), and it can sometimes be a bit misleading.

Why not have, say, 64 colors that are used to randomly assign class colors? Or better yet, just use a randomly generated color within a range of shades? It's such a simple change yet it would have a meaningful impact on the developer experience (well, at least mine).

The LabVIEW Robotics Module consists of a variety of sensor and actuator drivers, motion algorithms (such as kinematics), world map creation and search algorithms, a world simulator, etc.

It hasn't been updated since 2019 and is 32-bit only.

I would like to see it made open source.

I believe some or all of the sensor drivers are already available on ni.com/idnet.

There are several other VI-based components and examples that are standalone and could be easily released independently.

I realize that the simulator might have some 3rd party constraints for releasing as open source, but I'd love to see it released if possible.

View All (2)

"Find" -> "Class Constant" option

Add a function to Change Directory

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

But...if it's a class override method, I can't do this:

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up. This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

Allow a general purpose "on Save" hook

and is a more general request.

Have the ability to run custom scripting code on a save event.

What problem does it solve?

For me personally, I am working on an autoformatter. It would be nice to run that everytime something is saved. Right now I have to monitor the source folder from outside LabVIEW (using Python) and then use G-CLI to run my formatted. I'm sure there are probably other ways to do it and an onSave hook seems like the best choice.

I'm sure there are plenty of other use cases. Perhaps some kind of linting or enforcing some sort of style guide. ie if you save a VI without a description, it won't let you unless you enter a description. Perhaps even every time you save a file, run some unit tests?

Ideal Solution

Ideally the scripting code would have access to the reference of the thing being saved. The easiest thing to envision is a VI, but why not also classes, libraries, the project itself? Maybe also some indication of what triggered the save. Was it a saveall, a save all this library, etc. Maybe if it is a saveall, you get a list of all the things being saved, before anything happens?

The IDE would then wait to continue until the scripting code completes, maybe even failing to save on an error or a boolean - not sure if that is the best behaviour as in a bug in your scripting code could cause you not to be able to save - so maybe some way to override the hook?

Maybe include a way to autogenerate a VI with the correct connector pane.

Maybe it makes sense to generalize this to add more hooks into LabVIEW? Perhaps a call to update the project provider to something more usable/less user-hostile?

View All (3)

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

When is LabVIEW going to get with the times?

View All (1)

Improved PPL Debugging

I've encountered quite a few limitations when debugging debuggable PPLs, and feel that a number of improvements could be made to this process. I often find myself having to open a second project with the specific dev library in it, and then toggling back and forth between the two which is both confusing and inefficient. This is just scratching the surface, but here are some improvements I'd like to see made:

Non-editing menu options should remain available. One I use quite commonly: right-click on a class cube, and select "Show Class Library". But it's not available:

The workaround I use is to "Copy Data", press ctrl+n to create a new VI, drop the class cube there, and then right-click on that and select "Show Class Library", then toggle back to the temporary VI and close it.
VI Properties aren't available in VIs:

I often want to double-check reentrancy settings on VIs to ensure everything's configured correctly.
Private class data isn't shown. I get why this isn't available in non-debuggable PPLs, and I understand that there's a healthy debate that can be had as to whether or not this should be available in debuggable PPLs. I'm of the opinion that private data should be available in debuggable PPLs as they are meant for debugging, not for distribution.
Private class methods don't show up in the project. But if you click on the sub VI for a private method, you can open up the block diagram. If the block diagram is accessible, it really should show up in the project. I often find myself searching for a VI in the project, and not finding it anywhere, because the method is private.
Unusual interactions. I've seen a number of scenarios where I'm prompted with requests that I shouldn't be asked. For instance, if I double-click on a malleable VI in a PPL's block diagram, I get this popup:

The array "Startup/Always Included" carries these Vi's into pre/post build action VI's.

The order of the vi's in this array depends on the order they have been added to/created in the project when, not the order they can be seen on the project window itself.

Here's the project window:

Here's the order within prebuild vi:

The order is NOT the same. "startup" is the first but if you delete from the project and then re-add it, it will become the last.

I suggest that the order in pre/post build VI should be:

first - startup.vi

following: always included vi's in the same order they appear in the project window.

Also, the always included list should have a 'mechanism' to change the order of the vi's in the list - be it up/down arrow buttons on the side that would move the selected vi or a similar command in a "right click" drop down menu.

In this way, any pre/post build action that may involve any of these vi's can be clearly defined and remain stable during the lifetime of the project without running into the risk of getting the wrong vi to "work" on or having to edit the pre/post build vi to add or edit the vi's names every time there is a change in the startup/always included list.

LabVIEW Idea Exchange

Error functions should be located in a dedicated palette named “Error Handling” (or similar)

Whether Automatic Error Handling (AEH) is enabled or disabled should be indicated on the block diagram

Restore build speed performance for continuous integration jobs

New Certification Suggestion - The CLG

Auto select tunnel mode based on source and destination

Auto-wire cases inside loops when adding shift registers

When right clicking boolean, replace Create > Constant to Create > Create True Constant or Create False Constant

Overhaul the LabVIEW Style Checklist inside LabVIEW help

More Colors for Classes

Open source the LabVIEW Robotics Module

"Find" -> "Class Constant" option

Add a function to Change Directory

Dynamic/smart Index/scrollbar on array constants

Drill-down debug capabilities for class overrides

Allow a general purpose "on Save" hook

Allow Web Based Help for lvclass, lvlib, XControl ,etc.

Allow changing branches in Source Code Control without having to close project or exit LabVIEW

Improve readability of VI's membership in window title

Improved PPL Debugging

Better defined order of startup and always included VI's in Pre/Post build Action VI