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!
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.
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.
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'
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!
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)
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.
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.
"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.