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 working on VIs that require large arrays or images for input, I often need to run a calling VI rather than the VI I'm currently working on, which involves a lot of tabbing between windows and clutter from having more open windows. I realize it is possible to set default values for controls, but I would rather avoid that as I often use optional connections to my SubVIs and therefore don't want to change default values. In my opinion it would be useful to have the option to configure the run button to run a different VI than the currently open one, when working on VIs specifically developed to run as subVIs in the context of a higher-level caller.
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
When you right-click on a connector pane terminal, a context menu pops up -- but there isn't a good indication of which terminal you've clicked on:
You could assume that selected terminal is at the top-left corner of the context menu, but (due to a bug, I'm assuming), the actually selected terminal is a few pixels down and to the right of where you clicked.
What if the terminal you right-clicked on got highlighted while the context menu was shown? This would provide visual feedback of the selected terminal, giving you confidence that you clicked on the terminal you thought you clicked on (and avoid mistakes of configuring the wrong terminal). I can't even begin to count the number of times I've set the wrong terminal to "recommended" or disconnected a different terminal than expected. Could look something like this:
(which just piggy-backs on the appearance when you're wiring up a terminal:
Bonus points if the bug gets addressed where clicks are actually a few pixels off.
LabVIEW 2020 allows you to remove the event property nodes shown here:
It's a nice feature because these nodes are often not used and can get in the way. However -- the process for removing them is a bit tedious: you have to either remove them all individually or size the cluster down to one and then remove through a menu. I find that I rarely use this because, well, it just takes too long.
However...if you could just click on the node (it's already selectable) and then click the "delete" button on your keyboard, this process would be near-instantaneous, and I know I'd be much more likely to use it.
Windows 10 now handles long file paths although it has to be enabled with via various possible registry or group policy edits. Windows applications have to opt in. LabVIEW source code should be able to utilize long file paths.
If you've got a project open, any new VIs you create automatically get added to the project. It'd be nice if there was a way to disable this feature.
I find the feature frustrating because:
- I often create new VIs that I never intend to save, just to test out some logic quickly. However, I can't just close the VI -- I need to go and remove it from the project too -- and this also leads to a dirty dot in my project (and extra work).
- I'd prefer to have full control over which VIs get added to my projects, and where they added within a project.
- If you've got more than one project open, you have to be careful about where you press "ctrl+n" from.
- I've found myself in situations where I close a project after creating a new VI, tell LabVIEW that I don't want to save changes to the project, and by doing so inadvertently lose the code in the new VI because I'd overlooked that automatic association.
but that one was more generic to get the a subpanel reference from within the subpanel.
(My specific use-case is to create a fancy menu popup relative to the clicked item within the subpanel- basically, I need screen coordinates of the "thing" inside the subpanel, which I cannot get without coupling the subpanel VI to the main VI by providing an upstream VI reference, which I don't want to do.)
I have a 3D set of data, to which I fit a plane, and then from that plane fit a bounding box which should contain 99% of all data.
I would really like to plot both a scatter of the source data, and the surface within the same plot. Ideally the box would have transparency, but even lacking transparency it would be very convenient in visually confirming the quality of the fit.
There are two things that bother me about the index array. I think these changes would be useful to nearly all LabVIEW users.
The default value is not optional (for integers always zero, a very useful value) There should be a way to set the desired value if the index is out of bounds.
There should be a way to get rather the index is out of bounds from this primitive since this has to be check anyhow to know whether to use the default value. should look something like this:
The lack of these items usually proves to generate code that looks much uglier than necessary.
Although I do not know the internal workings of this primitive it would be hard for me to believe that this would have much of a performance impact. Also, bound checking arrays is necessary for many algorithms, why do it twice?
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.
I have two arrays I'd like to pivot into an array of clusters of a particular typedef. I could index and bundle it myself, but it's just weird that I can't use this builtin function just because the typedef has an element that's an array.
Also, it's kinda weird that it won't take a typedef as prototype. Casting it after takes up about as much room as doing the bundle in a loop!
I can see some reasons that letting us pass in 2D arrays would lose the tight optimization of the original (maybe it can compile-time determine the size of the cluster elements if none of them are arrays... except that you can put in object data. I guess either that's a reference under the hood, or there's some other reason)
Or maybe it's that it could cause confusion between making a 1D array of clusters with 1D arrays, or making a 2D array of clusters of single elements? That seems like it could be solved either by only doing the former, or requiring a typedef in that case, to disambiguate.
If you are instantiating classes dynamically or calling VIs dynamically through VI server, you may need to include the source files under "Always Included" when creating a build. If you are dealing with a large number of files in a multi-developer environment, you might also be using an auto-populated virtual directory. The problem with this is that everything under directory will be included in the build. Say you are building a hardware abstraction layer with 100s of different instrument drivers, you will likely have all sorts of different files like programming manuals, unit tests, project files, lower level instrument libraries, and VI trees. You might not want all of these files included in the build. Some of the files might not even compile (ie. VI Trees), which will prevent you from creating a successful build. If you are instantiating the classes dynamically, all you really need to do is include the lvclass files since that will automatically bring in the dependencies for that class. You could separate these files, but it would likely be a less cohesive directory hierarchy. For example, if a developer is implementing a driver they will probably want to access the programming manual under the same directory hierarchy, while at the same time, a programming manual probably wouldn't be beneficial to a user when the build is deployed so you might not want it included. Being able to define 1 or more file type patterns on either auto-populating virtual directories or on the build specification UI for source files, would quickly resolve this issue.
We could add a way, for example a parameter key in INI file of LabVIEW.exe, in order to run LabVIEW.exe silently, so without the splash screen and the getting started window, like a background process.
Right-clicking on a VI in a project and selecting "Find -> Callers" doesn't list any .lvtest files which call the VI in question. I think there should be a relatively easy way to find which unit tests call the VI. I use Find -> Callers when I'm refactoring, and want to know what code might be impacted by a change. It'd be nice to quickly find the unit tests which also call the VI.
Option 1) Have Find -> Callers include .lvtest files in the results alongside calling VIs.