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!
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.
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'
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.
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.
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)
I would like to suggest any labview program that uses simple codes (which doesn't use rio, dac and all) should be given inbuilt options to be converted as a .apk file for android systems. so the mobile's Bluetooth or wireless networks should be able to utilize the code without the aid of computer system.
Actually I developed a code for getting data over WiFi and process it through labview, if it can be converted into an application file that can be used in mobile phones means i can further enhance its use for my graduation project. Please let me know if there are possibilities.
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.
Is there any instance where it's good/ok to overlap objects? It should be prevented by LV. If you drop an object on top of another object it should move it as needed to prevent overlapping.
It'd be similar to the Auto grow, but would apply to all moved/placed objects.
More by chance than anything i noticed a strange look on one VI in an old project and after a short investigation it turned out there were 2 VI's on top of each other! One had no inputs connected and this could explain some behaviours we've seen before, as this results in a race condition where one uses the default values.
At some time this VI was probably moved with Ctrl pressed as part of cleaning up the diagram ... had this suggestion been in place it'd have placed itself to the side clearly showing there were two!
"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.