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!
When developing a Complex LabVIEW Applications, we may need to create N Number of Folders as a part of Configuration information.
This requires the developer to make a check "Check if File or Folder Exists"
Instead of that Create Folder Function can have a Boolean "Optional Input" to create the Folder only if not found in the specified Location and Eliminating the Error when trying to create same folder again.
A LabVIEW application installer generated from App Builder creates multiple folders and files in the folders. It is desirable to have a single file installer so that customers see only 1 file to install.
A right click option for each auto indexed array that allows will not use the length of that array in choosing the number of iterations. If there is no input to the count terminal all auto-indexed terminals can go beyond their length otherwise at least one must remain as a driver for determining the length. If multiple are left with the default (existing) behavior, the shortest length will be used. For any iteration where the array is shorter that the "i" of the loop, the defaults for the data type will be returned (just as if "index array" blocks had been used inside the loop.
Similarly the loop could be set to use the longest array instead of the shortest.
Additionally a similar function could be done when any array compare or math functions are done. In the case of compare functions if set to use longest array, the result will be false for any compare to an empty element of the shorter array, and math functions will use the default data type for empty elements.
The In Place Array Index/Replace Elements function not only can save memory by avoiding copying arrays, it can also create "neater" and more transparent Block Diagrams. For example, here are two ways to triple the third element in an Array of 3 elements:
I needed to do the same thing, but for a 2D array (three channels of A/D data, I wanted to triple the third channel). The Help for the In Place Array Index/Replace Subset function suggests this is possible, using language like "element or element(s) of an array", noting the similarity between this In Place Structure and the two Array Functions that form the Input and Output nodes, and in earlier versions of LabVIEW (specifically LabVIEW 2012), explicit reference to rows, columns, and pages as replacement items. Here's what happens:
The Index Array left node forces you to specify both row and column, meaning you cannot operate on a single row (or single column), "breaking" the functionality with the separate Index Array/Replace Subset functions. This also, I believe, will force an Array Copy operation, something I'm (also) trying to avoid.
At its most benign, there is a Documentation "Bug" that should warn users that this In Place function is only designed for single array elements (which, in my opinion, severely limits its usefulness). I would like to suggest that this function be "fixed" to (a) for multi-dimension Arrays, allow, as with Index Array and Replace Subset, flexible choice of one or more Indices to be specified, with the unspecified Indices implying "All of the Elements", i.e. an entire Row, Column, Page, etc, and (b) maintain the "In Place" functionality by having this function generate the necessary code (behind the scenes) to access the specified elements and do whatever operation is required inside the Structure.
I appreciate that requirement (b) might be difficult. For instance, operating on a row in a 2D array should be easy, as the (row) elements should be continguous, making getting and putting them simple. However, if a column is specified, getting successive elements and putting them back becomes more complex. To the User, it all "looks simple" -- you get a 1D wire out, operate on it (say, multiply it by 3), and stick it back "in place", but the LabVIEW compiler has to "get" elements from non-continuous locations and put them back where it got them, but that's what Compilers are for!
When a string control, indicator or constant is switched from any mode other than Normal Text, display a small glyph (similar to the radix indicator on numeric controls) to allow you to see that the display is something other than Normal Text.
I'm not sure if this is a bug report or a feature request, but I think it should be fixed/implemented, all the same
If you right-click on a Boolean funtion (And, Or, Exclusive Or, Not, etc.) and replace with a Compoint Arithmetic (CA) function, the CA function is always set to the "Or" configuration. I would expect it to be smart and put the CA node into a configuration (including negation/inversion dots) that is equivalent to the Boolean function that it replaces.
It would be a small yet very welcome improvement if the 'size to text' option could be added to the enum and ring options when in arrays rather than having to manually adjust them.
Here we have a combo box vs enum in an array. Both contain identical lists which consist of the following:
Now if you right click the combo box you get the option to size to text: Right click the enum and you don't:
Also, when you 'size to text' on the combo box list, it sizes to the item you selected rather than sizing to the longest string as shown here:
Yes you could argue that it did exactly what you asked but my preference, and I'm sure others will agree, that it would be best to size to the longest string. Maybe have two options in the list. 'size to current element' and 'size to longest element'
Sometimes when dealing with the Bundle/Unbundle by Name nodes, I start with more elements than I actually end up using. Then, my block diagram looks something like the following:
Maybe I'm just lazy, but I really hate removing each unused item from the Bundle/Unbundle by Name node over and over. Right click on unused element, click "Remove Element", Right click on next unused element, click "Remove Element", etc... Ugh!
So I'm suggesting a "Remove Unused Elements" when you right click on a Bundle/Unbundle by Name nodes. With this option, right clicking on one of these nodes would look like this (emphasis added ):
The result of this operation would look something like this:
Now I can spend my time coding instead of getting rid of individual elements! Thoughts?
Many times a while loop needs a delay for one reason or another, even if its just to add a small delay so the program doesn't peg the processor. Having this would clean up BDs, and it would also act as a reminder to make sure your code doesn't peg the processor. (with nothing wired to it, it would default to zero)
If there is a "Move Up" and "Move Down" option is available for "Unbundle by Name" and "Bundle by Name", then it would be very helpful. Then, instead of deleting the removing the items and then inserting the same item in some other row, I will just move it up or down....
The useful feature of having an arrow connect a free label to the part of the code it refers to was added in LV 2013. However, there are cases where a label refers to multiple objects, so you would want to point an arrow to each of those objects. Currently this is unavailable. I suggest that this feature gets implemented in following LV releases. It makes block diagram documentation just that bit better.
"Which I think should NOT be the default behavior: It "fixes" potentially incorrect code by throwing even more potentially incorrect code at it. I can't remember a single instance where I wanted that behavior."
While I wish this option would disappear completely, I think at least it should be off by default.
There are plenty of examples (e.g. here or here) where an auto feedback node insertion covered up a serious dataflow issue by making the VI no longer broken. This is a disservice to the new programmer who might not even understand what a feedback node really does.
A feedback node needs to be intentionally placed in all cases.