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 I try to select a word or more words I currently have two options. The first one is to hold down shift and select on letter by letter basis which is slow. The second one is to select with help of mouse, which is error prone.
Normally all text editors have options to move for 1 word left or right by ctrl + left arrow or ctrl + right arrow. The same goes for selecting a word (ctrl + shift + arrow). I would like this functionality to be supported by LabVIEW at least on block diagram, VI documentation, enum editing.
At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.
Of course I could use CTRL+G, but I'd still need to clean up the opened windows.
Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.
It would save me tons of time if the search results window had a preview of the result:
The found item should be in the center, preferably highlighted in some way.
It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!
Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.
FIR Filter is almost the same as convolution, except that it has a init/cont terminal while convolution has an input for algorithm (Direct, frequency domain). FIR filter always uses direct convolution.
If "cont" is not used, convolution based FIR filtering could be orders of magnitude faster because it scales much less steeply with input sizes. Examples have been discussed where switching algorithms from "Direct" to "frequency domain" can turn minutes into seconds (e.g. 1M points and 5k filter).
While the knowledgeable programmer can of course make his own using the convolution primitives (also programming around other limitations because this idea is not implemented :(), it might be more intuitive if the FIR Filter had an "algorithm" input where we can select between the same choices as for convolution. (From my casual understanding, "frequency domain" would ignore the "cont" input because it is incompatible. This can just be mentioned in the help.)
Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.
Look at the picture: As programmer of the application "main.vi" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.
As reference: This is the content of Class 1
What I suggest and expect is the following:
=> The class tree shows all available methods within each single class!
bright colors: Methods that are defined in this class; pale colors: inherited methods
Please address the problems/shortcomings when setting file security permissions in Windows File I/O. The current Get Permissions and Set Permissions File I/O vis do not work.
Currently when LabVIEW creates a file it assigns the default security permissions, which are inherited from the parent directory. This is a pain as the current user is allowed, in general, read and write access, but other users are potentially only granted read access. For example, creating files in the public application data directory (as the sample projects demonstrate for storing settings) means that only the user who first created the settings file can update its contents, whilst other users will get a file permission error.
At minimum, I would like to be able to specify what kind of access other users should have when creating a file. Better still, I would like to be able to get and set security info. Currently I am forced to call functions in advapi32.dll to set acceptable permissions (e.g. GetNamedSecurityInfoA).
Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.
I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either.
When you mass compiled, all VIs in the directory tree get recompiled. When you hold CTRL and SHIFT and click the run button on a VI, it forces a recompile of all VIs in the call chain.
However, when you CTRL-SHIFT-Run, all you SEE is a busy mouse; it would be really nice if you could get a popup windows (the same as when you mass compile) showing what's going on, and giving options to cancel... it would also be nice to be able to specify a log file and how many VIs to cache, same as with mass compile...
It could be the same popup with a different title...
There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:
Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.
in many cases after wiring in the loop , we will go for the shift register to store variable. but in case of changing the loop tunnel to shift register left side tunnel required to connect manually.if not it creates the another tunnel in the loop.
in the loop , if the left and right tunnel variable are same , LabVIEW automatically replace tunnels with the shift registers.
I have been pretty slow to pick up the addition of quick drop functionality. This is mainly due to the list of shortcuts being out of the way.
I have always thought it would be easier to get the hang of Quick Drop if I had the option to put the quick drop shortcut in parenthesis next to the object name in the function pallet. That way when I go back through the "normal" way of programming I will see the shortcut each time and over time I could get the hang of each objects shortcut.
I often create maps in a for loop, as shown below. However, the "Insert Into Map" value input doesn't adapt to the value type, leading to extra hurdles in order to create the correct map constant to feed into the for loop/VI.
It'd be cool if I didn't have to do the extra work to create this map constant. Ideally I'd be able to wire any value type into the "Insert into Map" VI, and then just right-click on the output terminal and select "create constant".
(It appears that you can now drag and drop a value type into a map constant which does make it easier, previously I would "build map" node in, get the constant it from it, and then delete it. Either way, it's still extra steps.)