LabVIEW Idea Exchange

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

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?

 

_carl_0-1763139909538.png

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.

_carl_1-1762465278673.png

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.

 

Proposing adding right-click menu option for bundle and unbundle cluster elements, which allows the user to rearrange the order of elements with wiring automatically updated.  This is a frequent and tedious task when cleaning block diagrams that currently involves many steps and introduces risk of mis-wiring - this change would leverage existing behaviors to reduce time spent cleaning block diagrams.

Robzilla_0-1762462236224.png

 

Surrounding structures should not grow while I´m typing in a string constant or comment.

Only afterwards when I move or resize the string constant or comment.

Existing right click menu during wiring provides options to create terminals or wire branches.   Proposing a feature to add a cluster unbundle terminal when wiring clusters, that places and wires the terminal with the desired element reference.

Robzilla_0-1762307860683.png

 

When drawing a selection rectangle that covers part of a cluster, structure, or wire, you can toggle selection of the entire thing by hitting the spacebar. (https://www.ni.com/docs/en-US/bundle/labview/page/selecting-objects.html)

 

I propose the same functionality with arrays. It's odd to me that this handy feature works with clusters and not arrays.

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:

 

_carl_1-1761599933386.png

 

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:

_carl_2-1761600292434.png

 

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.

 

 

_carl_0-1761239244468.png

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:

_carl_0-1761236480557.png

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.

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.

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)

MECSO_0-1761043766847.png

 

Problem

I would like to create HTML report of my unit tests run together with information about project code coverage. This can be achieved if the "Generate HTML report" option is checked in Project>>Properties>>Unit Test Framework and when the tests are run via toolbar operation "Run Unit Tests". However, I want to create same HTML report with PROJECT CODE COVERAGE programmatically via "Create Report.VI" or CLI, but the report generated in this way doesn't contain the code coverage information.

Run via Create Report.vi

bender_robotics_4-1760687909082.png

Run via toolbar

bender_robotics_3-1760687866751.png

Why This Matters

This functionality can be useful for running unit tests and report creating via custom CLI operation for CI. My scenario is to use the report as an CI artifact with informative value about code coverage.

It would be nice if the format to string would support arrays.
Something like this:

MikaelH_0-1760513019416.png

 



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.

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:

raphschru_1-1759327735617.png

 

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

Hi all,
when I use breakpoints for debugging, I found that the breakpoints sometimes automatical re-appear after they are deleted from the breakpoint manager. I did some tests and found that they only appear again, when there is no other change in that VI, so the VI is not marked with the * in the title, which indicates unsaved changes. They will also not reappear when the VI is saved manually after the breakpoint is deleted.
So the suggestion is that a VI should also be marked as unsaved after deleting a breakpoint.

 

Regards, Patrick

Hi all,

I' normally using one or multipe queued message handler with a clustered enum (which is saved as Type Def.) and a variant as a basic architecture of my programs. This makes sense and it is relatively easy to search forward and check a program step by step. Unfortunately, it is not so easy to go stepwise back in the program for debugging., especially if there are multiple callers of a function.
Therefore I wish I have a function, where I can search for a single item of this enum Type Def.
I know that there is a possibility to search a text and of course it will find these items, but is also finds all other kind of things labeled the same.

I had a small chat with a engineer of NI already and we had an idea to gerneralize this a little to give it more use cases. 
In the current situation, we can search for a:
- Type Def. , but then it will find each item of the enum OR
- text, but then it will find all items labeled with this text.

So here is our idea:
Create a possibility in the search window to combine these 2 search formats with a boolean operator, in our special case, this would be AND. But in other cases it might be also useful to have some other operators.

You are welcome to share any thoughts about it. 

Best Regards, Patrick

Problem

I find myself wanting to Ctrl+Drag to add/remove diagram space INSIDE of a structure without actually resizing the structure itself AND without modifying any other frames – I just want to clean up the visible diagram that I am working on.

However, this is not how LabVIEW currently works – the structure itself is also resized, and the space within other frames of the structure are resized as well (outward/inward from the same point as the Ctrl+Drag action), which can mess up both the code in other frames as well as the code outside the structure.

Proposed Solutions

Option 1: Lock Structure Size Add the ability to lock the size of structures (or perhaps only lock them from growing during creating/removing space), so that I can use Ctrl+Drag to create/remove space without impacting the structure and the code around it. This would be similar to "Auto Grow" but would perhaps be an "Allow Grow" or "Lock Size" setting.

Option 2: Modifier Key Use the Shift modifier during Ctrl+Drag and Ctrl+Alt+Drag to NOT resize the containing structure. This would maintain backward compatibility while adding the new functionality.

Why This Matters

When working on complex VIs with multiple frames in structures, it's frustrating to have simple diagram space cleanup operations affect the entire structure and surrounding code. This feature would allow developers to better organize/tidy the code within individual frames without the ripple effect of resizing everything (in other frames and outside the structure).

 

I'm not sure if someone has requested it yet, but it would be very helpful if I could clear the probe watch window of the last retained values. This way I don't need to look at the timestamps and it will speed up the debugging.