Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
While debugging LabVIEW, we often have many VI windows open. It can sometimes be difficult to manage these windows, especially once the debugging session is over. I think we can improve this situation greatly with a minor change to the All Windows dialog. This dialog (launched from the 'Window' pull-down or by pressing Ctrl-Shift-W) currently shows a list of all LabVIEW windows that are currently open:
There are several columns of information describing all the open windows, and the list is sortable by clicking a column header. You can multi-select in the list and click 'Close Window(s)' to close multiple windows at once.
Idea: If we add a "Time Opened" column that lists time stamps of when the windows were first opened, it would be easy to sort by that column, then close all the windows that were opened during a span of time, i.e. while debugging.
While we're at it, there are several other usability enhancements that could be made to this dialog that seem to be low-hanging fruit:
Make the window a non-modal floater, with the list dynamically updating as windows open and close.
Add a 'Minimize Window(s)' button.
Give useful key navigation to the 'Close Window(s)' button (and any other buttons we may add).
I know there are other ideas about making debugging easier (don't show panels, etc.). I'm scoping this idea to improvements we can make specifically to the All Windows dialog to make debugging easier.
The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.
I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.
The enum has a built-in right-click menu to 'Select Item', but it's worthless... it does exactly the same thing as clicking on the enum directly:
I think we should replace the 'Select Item' right-click on enums and rings with a Quick Drop-like UI that lets you filter the enum/ring contents and select an item without having to scroll a giant list:
It's not a BUG it's a FEATURE.... that's why I have to present it here.
When the digital display is visible on a ring or enum, the option to display the radix should be present. I can't tell if a displayed value of "401" is hex or decimal without looking at the display representation...
(note: this idea is similar to this one, but different enough that I thought it warranted a new post)
LabVIEW 2019 will include a Clean Up Front Panel feature that repositions front panel objects to match their positions on the (already wired) connector pane. I think we should also consider implementing the opposite behavior, where you can arrange your front panel the way you want your connector pane, then assign that arrangement to the (currently empty) connector pane:
I envision the gesture used to employ this feature would be a Quick Drop Keyboard Shortcut, an entry in one of the drop-down menus, or a right-click on the Connector Pane.
I find it always a hassle to create an asynchronous call with the need of the "Open VI Reference" block. A strict static VI reference should be sufficient. Options should be either available in the properties via context menu, via property node or as input of the "Start Asynchronous Call Node".
I didn't go through the effort to create a property menu example, but here is an a graphic showing the help example and what I would wish for:
For about a decade and a half I have consistently changed the default block diagram grid spacing to 4. Why, to match the shift arrow moves. Hold it! Why not make the shift arrow moves equal the grid spacing?
A quick one-button solution to view pre-configured Design Rule results per VI. Not quite an analyzer. One layer (VI) deep. Pull-down icon changes from green check mark to the Alert symbol suggested here if violations exist.
CTRL+Click on an input is a great little tool to switch the input.
However, it only works when both inputs are wired. Often (, I or QD connected a wire wrong,) I feel like switching the input, before wire-ing the 2nd. Only to find it doesn't work...
Having to connect the 2nd wire just seems to disrupt the flow, being focused on the first input. Being forced to make things worse (connect two wrong wires) before being able to make it right just feels itchy to me.
It's a minor thing, but I never understood why it would be limited to 2 wires.
There are cases where a variant constant / control needs to have a data value. This can be done by right-clicking a control / constant, selecting Data Operations -> Copy Data, then right-clicking the variant and selecting Data Operations -> Paste Data. This can be time consuming for many variants.
The idea is to allow dragging and dropping of a control or constant onto a variant, and have the data copied to the variant:
There are already a couple ideas to retain wire values on a hierarchy (here and here). This is a request to disable (or toggle) the 'retain wire values' option on all VIs of a hierarchy in the same vein as 'disable breakpoints on hierarchy'. This request was spurred by an investigation into VI performance on resizing a very large 2D array of strings, wherein several memory allocation strategies and lookup strategies (arrays, maps, variants) had been exhausted, only to discover that a subVI whose (front panel and diagram had been closed) was set to retain wire values. Merely toggling the retain wire value setting off on this particular subVI improved performance by approximately one order of magnitude for this particular project.
Investigating and accurately measuring run-time LabVIEW performance can be challenging with so many debugging tools available, the impacts of which are not immediately obvious. For this reason, I would like to see a menu option that recurses on VI hierarchy and toggles the 'retain wire values' option, in the same vein as the option which removes all breakpoints from VI hierarchy. The option would be very helpful with run-time performance investigation or optimization.
OK, using Malleble VIs is cool. Imaging being able to not only wrap code around a variable datatype but wrapping an object around a variable datatype.
I personally have quite a few classes which do pretty much exactly the same thing but which only differ by the precide datatype contained within its private cluster. No changes in the number of elements, no changes in methods, only the datatype of the specific data.
Obviously, the datatype would have to be compatible with all methods and VIs of the class which use that data field or we would have broken code.
When I print a front panel containing a graph (who ever does that?) I get a stunningly beautiful publication-quality render of my data (overlooking the poorly done vertical y-axis label). However, all the many options of directly exporting a graph image (detailed here) ultimately provide only a screen-resolution image. See the contrast in image quality below:
Printed front panel vs exported graph image.
This idea has been discussed ad infinitum on the forum (see, for example, here, here, here, here, and here), but has never been adequately resolved. (Enlarging the graph for export does not work since graph elements do not scale, so lines, points and labels end up being far too small.) High time to implement a feature that has been in demand since (at least) 2002!
When you use Quick Drop to insert a division operation onto a wire: you almost always want the numerator to be automatically wired, and the divisor to be unwired. Yet, Quick Drop always wires up the denominator.
when using the shared variable multiple variable editor to bind shared variables between the PC and cRIO its an annoying UI experience when doing more than a couple of bindings.
While the dialog can be resized, the new size is not remembered when binding the next variable, and its current size / layout is not useful for showing trees.
Also it doesn't remember your last position in the tree - so every time you wish to bind a variable you have to click to expand cRIO, click Chassis, scroll and click Module then scroll and find the variable by luck as you can only see the first few characters then click again.