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!
what do you think about a "feature" where developers can enforce version control on applications deployed into end-user systems? it may sound something like some feature of a certain OS, but it may be beneficial in a way or two...
the most obvious being for version enforcement, some members may not like this, but often time newer versions of application are developed to address certain issues of the previous version, and it would be pointless if the end user kept sticking to the old version for certain feature they may have grown to like
it can also be extended to subscription based or trial version deployments, a more friendly way for developers to present their systems for customers for in-situ system trial
one way to deploy this feature, is to minimally trace the execution instances of the RTE in deployed systems, across newer and older version, log them for follow-up actions, that can range from friendly popup reminders for update to application execution prevention.
Using a ring control, it would be really nice if LabVIEW allowed the cases of a case structure to be defined by the ring contents, like an enum does rather than the ring value. It would be easy to force it to have a default case to handle values that aren't defined by strings in the ring. Just make sure you can still right click the case selector and tell it "add case for every value". This would be very helpful when creating code to handle exceptions that return values in a ring and you want to handle each case. It would be much quicker and less error prone than manually adding each numeric case that's defined in the ring.
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?
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:
(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.
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.
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.
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.
We like to keep the OS installation clean/stock. That is, install RHEL and any packages required for the engineering applications and try to keep the installation packages to the minimum that are required. Typically the EDA vendors will have a script that checks that all of the Linux package required the application. If we find any dependencies we install on all machines. The LabView Linux installation script wants to be run as root and install packages. Would rather see a dependency check script so that we can install the dependencies ourselves and know what is being installed.
For the application tool itself we don't want to install in /usr/local on all machines but rather install into a NFS mounted file server so that we only need to install once and not install on each machine individually. The current Linux installation script doesn't take an argument to specify an installation directory other than /usr/local.