LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

In previous versions of LabVIEW (including 25Q1), if you right-clicked on a wire, you could navigate directly to the Breakpoint Manager. With the merging of probes and breakpoints in 25Q3, the "Breakpoint Manager" has been replaced with the "Debug Window". However -- there's no longer a right-click shortcut on wires to navigate to it. I'd like to see this brought back, as it's a more intuitive location to find it than the View menu. Finding it for the first time after the switch wasn't obvious either, because of the name change.

(And yes, I'm aware that there's now a keyboard shortcut to directly access the Debug Window (ctrl+d) which I'll be using in the future, but I wouldn't expect most users to have this memorized.)

Built-in DVR Call Wrapper

DVRs are extremely powerful, yet tedious to work with. Much of the coding is just a matter of following the exact same pattern over and over again, while making the code uglier. And I have yet to come up with a good way to reduce that coding overhead...

What if there was a built-in DVR call wrapper that allowed direct access to VIs?

The UI experience could be a hybrid of the Static VI Reference and Call by Reference functions: drop the "DVR Call Wrapper" on the block diagram, drag your VI into it, then wire it up directly.

It could have options for write and read-only. And it could have right-click options for changing default error behavior.

My standard use case would be class calls specifically, but I don't see a reason this couldn't be applied to any data type -- although some serious thought would have to go into expected behavior in terms of which terminal to treat as the DVR (although this could be dynamic based on which terminal a DVR is wired into, or maybe even settable on the wrapper).

A tool like this would likely save me countless hours of development time, and make it less likely that I'd make coding mistakes while writing routine code.

The LabVIEW equal comparison function considers NaN to be be not equal to NaN. Mathematically, this makes sense. However, in practice, this isn't always the desired behavior.

One example: When writing unit tests, I often want to check to see if output clusters match expected results. This might look something like the (overly-simplified) code below. Equals comparisons (when changed to compare aggregates) are fantastic for comparing these -- until you are checking that a result is in fact NaN.

The workaround involves writing a decent amount of error-prone comparison-checking code -- which would be entirely unnecessary if there was a built in comparison tool for this. This could be implemented as an extra option for "Comparison Mode" or as a standalone comparison function.

View All (1)

No autogrow while typing

View All (1)

View All (5)

View All (2)

I often use the "Find All Instances" option from the right-click menu when clicking on a VI's icon to find all callers of that VI. However, it regularly comes up with fewer hits than the "Find Callers" option. In this case, it came up with 0 hits:

However, if I navigate to the VI in my project (ctrl+shift+e) and then right-click on it and select "Find -> Callers" it will actually find the callers:

I've never understood this discrepancy, and I see it regularly. Perhaps this is more a bug than a feature request -- but I do feel that if these callers are consistently findable from through one of these mechanisms, they should be consistently findable through both.

Note: in the case above, if I do open the VI (after finding in using "Find Callers"), it will then be found if I "Find All Instances...". But if I close the VI, it's no longer found using "Find All Instances".

When you're looking at the front panel of non-editable VIs, such as VIs in PPLs, many options aren't available. Some of these are still applicable, and would be really useful.

Example 1: If I want to go look at a class definition, normally I could right-click on the class in a front panel and then choose "Show Class Library". However, it isn't available if the VI is locked. My (less-than-ideal) workaround is to "Copy Data", drop the class on a new block diagram, and then I have access to all the normal menu options.

Example 2: The connector pane isn't visible. I often want to look at what is wired where on the connector pane, or to check if inputs are dynamic, but this info isn't visible.

I work with PPLs quite a bit...and sometimes...I just want to rename them.

Libraries that depend on the renamed PPL will then be broken, as expected. Example here:

It would be awesome if I could simply go in, right-click on the missing dependency, and replace it with the newly named one. But...for whatever reason...this option is disabled. Instead, I find myself having to go in and manually replace each individual broken PPL call (VIs, typedefs, etc.). This is unnecessarily time consuming and error prone.

Currently VI's show up in whatever taskbar's monitor they first showed up in and don't follow if they are moved to a different monitor.

This makes my workflow very difficult as I can end up with 18 VI icons (1 each block diagram and front panel) on Monitor 2 and 0 VI icons on Monitor 1. This despite the fact that might have moved have of the VI representations to Monitor 1. The only way to distribute them among the taskbars is to restart windows explorer. This is annoying to have to do even though I have a script to do it (thanks to the hero that posted that process!).

Relatedly, I don't always want all VIs to pop up when I want one to show up. I should be able to bring a block diagram up without having every other VI front panel and block diagram also pop up. Then I have to go and minimize each window individually so I can look at a document or spreadsheet at the same time.

View All (2)

We know that LabVIEW has some magic that it uses for automatic error handling. What if LabVIEW could use such sorcery to enrich the error string flowing on the wire, with information about the originating source of the error -- specifically the VI Reference and GObject UID of the node where the error was introduced. Then a "fancy error dialog of the future" (TM) could utilize those UIDs to navigate directly to the node and highlight it (a visual effect to show which node it is). This behavior could be added to the Simple Error Handler and General Error Handler VIs, and maybe ever there could be a "LabVIEW Gems" vi.lib utility that can extract the VI Reference and GObject UID for use in other, 3rd party tools.

View All (3)

Current Behavior of LabVIEW
Currently, the error messages that emerge from bad call to a Property Node or Invoke Node only state that the error occurred in a property node or invoke node.

User Need

As a user of LabVIEW, it saves me considerable time in development/debugging, when I can precisely know why and where in the code an error occurred , so that I can get on with the actual work of fixing the bug in my own code/logic.

Problem For Users

The current behavior, described above, makes it impossible to know (without placing probes and retaining wire values):

A) Which Property Node or Invoke Node actually generated the error (in cases where there are many of such nodes)? Again, all we know is that some Property/Invoke Node on the block diagram of the VI raised the error.

B) Which specific Property actually caused the error, in cases where a Property Node has multiple properties that it is reading and/or writing. Again, all we know is that the error occurred inside a Property Node.

Proposed Solution

Error message for invoke/property nodes should state:

- the Name of the Method or Property where the error occurred
- the Class Name of the VI Server Object (if available)

- the Object Refnum value (e.g. the hex value of the object reference)

- possibly even (only if running in the editor and not the runtime environment) the VI Server Scripting UID of the GObject node on the Block Diagram for super-fast debugging with a "fancy error dialog of the future" (TM) whose LV Idea Exchange post with undoubtedly be coming soon...

View All (3)

Especially when I use setting windows I normally transfer the actual settings from a setting-cluster or from global variables to multiple local variables and display the current settings in the front panel. After the user edited the settings of course the settings need to be transferred again to global variables or in a setting-cluster. So if multiple global or local variables are used, each variable need to be changed from read to write 1 by 1 by right click and selecting the action from the menu.

So I suggest to implement a function to change it at the same time for all marked variables, similar to property nodes.

The suggested procedure would be:

Mark variables with the mouse by holding "Shift" on the keyboard or drawing a frame
Right click to context menue
Change all to read / write

The feature would be consistent, because it is for example possible to create local variables of multiple controls at once with a similar procedure. (I just don't get in mind why the order is always upside down when I do this)

View All (3)

Use Nigel to suggest commit message

View All (3)

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.

View All (2)

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:

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

View All (4)

LabVIEW Idea Exchange

Add Debug Window (AKA revamped Breakpoint Manager) back to right-click menus on wires

To be able to change multiple front panel items style in one go

Built-in DVR Call Wrapper

Comparison Mode for Treating NaN's as equal

Add feature to rearrange cluster bundle / unbundle terminals

No autogrow while typing

Add unbundle to wiring menu for clusters

Toggle selection of entire array with the spacebar

"Find All Instances" of a VI should be just as capable as "Find -> Callers"

Show more data when looking at non-editable VIs

Allow "Replace" of Broken PPL Dependencies

Make VIs show up in correct monitor's taskbar and be independent of others

Automagically include GObject UID in error messages when running in the editor

Show VI Server class name and method/property name in Property/Invoke Node error messages

Option Change all to read/write for multiple local / global variables

isfinite(x), isinf() and isnan() for Formula Node

nextafter() or increment/decrement ULPs in SGL/DBL/EXT

Use Nigel to suggest commit message

Make creating subclasses less painfull

Normalize terminals height for timed structures and FPGA nodes