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!
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!
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'
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.
I have a project which compiles to 2 different executable for different hardware targets. I have created 2 Build Specifications which specify different locations for the build output. However, between compiling each one, I must go to the target options, and change a Conditional Disable Symbol definition so that the other .exe is generated. If the Build Specifications definition had a tab to specify the value of Conditional Disable Symbols, and which would take precedence over definitions in the project or the target options, then I could build my 2 executables without changing the target properties.
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?
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....
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)
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.
Currently, if you want to enter in multiple elements in an array, you have to click on the empty element before typing. It would be more effecient to be able to press tab to enter another element in that array.
When building applications that use many different toolkits and classes, my build times can skyrocket. It's frustrating that while i'm waiting for my application to be built LabVIEW is useless for development. This is especially aggravating when I find a bug that takes 20 seconds to fix, but then building the application takes another 20 min. To address this issue I propose that there be an option to launch the build process in a separate process from the IDE so that I can continue working with my code in the meantime. This could mirror the FPGA compilation process where it used to block development but now is separated out.
Why optional though? For smaller applications the build process is very quick so if you can live with it I wouldn't want to always introduce the extra overhead that I assume would be necessary to lauch the build as a separate process.