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 in LabVIEW NXG 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!
Sometimes it's very useful to modify a front-panel decoration element programatically. E.g. moving it, changing its size, color or visability. All of those properties do already exist but it's hard to reach them (if your read the other idea, you'll see that it is even imposible for a specific element).
What I'd like to have is a right-click-menu-entry "create property node" (same for method node). The result shall be a property node appearing in the block diagram which is linked directly to the decoration element.
Everyone knows, actual assembly and constructor selection through dropdown and objects is very painful.
Disadvantage: A programmer has exactly to know, what he search for and in which assembly he can find it.
Common .NET Editors supports users with dot notation and text recognition. e.g. Visual Studio
OK that is luxury and not necessary - but what about a simple filter input field like in "Edit Events" dialog?
To capture this in a nutshell:
- add a filter input field
- add a little bit luxury with dot notation and autocomplete
- maybe there is a way for remanent selection of some default assemblies (cf. Visual Studio) so that filter base is fast and assembly dropdown must not use all time
Benefit: Notation to select a constructor (or method or property in other nodes) is that the filter input string is similar to all .NET class documentations, tutorials and examples. Transfer will be much easier.
I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.
To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.
A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:
In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.
While there are ways to temporaily disable autowiring, some should never happen in the first place. For example if the resulting wire has a net right-to-left flow, it should not be created at all!
Let's have a look at the following simple scenario (see picture):
Place an "add" primitive (or almost anything else!), then use ctrl-drag to create a second copy right below it. (Sometimes we need to add a few different things in parallel!). LabVIEW immediately connects a random input and output with a circuitous backwards wire for no good reason at all.
If I really wanted them to be connected, I definitely would have placed them side-by-side!!!
Idea summary: if any auto-generated wire would result in a net backwards dataflow, it should not be created at all!
I have often the case, that i have to display an array of cluster. It takes a lot of space on the front panel to show all the captions of the cluster elements, cause they will be shown on each array element. A better solution would be, showing the captions or labels just on the top visible element.
The "Probe Display" pane of most default probes should have indicators that are set to "Fit to Pane". The worst offenders, in my opinion, are Strings and Variants...I often find myself cursing the fact that I can't see more of the data, and usually have to copy & paste into Notepad++ or something to actually see what I'm looking for.
Yes, you can make custom probes for this behavior. But it should be native.
So one shortcut I really like is CTRL+Shift+E. This shows a VI in the opened project and drills into dependencies, and libraries to show you where the VI is. The most common reason for me doing this is to find the library or class that a VI is in, and to find the other members within that library. One issue I have is if I open a VI that isn't in a project. This isn't very often but some times I want to work on editing a library or class that isn't part of a project yet and is just some reuse code that I intend on cleaning up.
When I open a VI that is in a library, but not in a project, CTRL+Shift+E does nothing, but what I think would be nice is if this same shortcut could be used when not in a project to open the Edit >> Browse Relationship >> This VIs Class and open the class to show where the current VI is in the class or library. Or alternatively this idea could be to make a new shortcut that does open the library or class a VI belongs to, and select the VI in a similar way to the This VI In Project works.
The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).
The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.
Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.
As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.
If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).
Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.
IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.
NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.
I suggest that NI start shipping USB keys instead. USB has several advantages:
USBs are smaller
USBs are more usable on devices without DVD player
Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.
My idea is to have LabVIEW cease and desist it's self-important modal behavior. Not that I think LabVIEW is anything other than the most important application I run, but I don't think it should force its (many windows') way to the front of the line when I shift focus to a LabVIEW window. I didn't find any other idea that matched this, but there is this discussion that covers the notion well.
An example case: When chasing efficiency I frequently have Task Manager open to observe CPU usage when I change front panel controls. I'll run the .vi and load Task Manager, but when I click on a front panel control ALL the LabVIEW windows come to the front and cover Task Manager:
So, my suggestion is to have only the selected LabVIEW window come to the front. I get the impression that Ctrl-Tab and Ctrl-e behavior are why LabVIEW controls its own window z-placement, but leaving their function out of it, my suggestion is just to change the modal behavior of LabVIEW windows.
Please make the next version of LabVIEW a major update of the features we have available to create user interfaces.
2011 was the "improved stability" version. 2014 should be the year it became simple and fun to create user interfaces that blow everyone's socks off. I'm not even talking about fancy stuff, just get the basics right! Fix the graph indicators, and provide better front panel scaling options - and that alone will make 2014 the best update ever(!).
I started writing a list of all the things I find bad with the graph/charts for example, and found out that it would be better to just do a search here on the idea exchange to see how many ideas mention graphs alone. 2390 ideas! (yes, I have not gone through them all to filter out the ones that do not actually request changes to the graphs, but most of them do, directly or indirectly...). My own little list started like this, in random order:
Graphs and charts
1. You cannot stack plots in any of the graph indicators, only in charts 2. Number of plots stacked cannot be varied at run-time 3. Annotation properties are only partially available programmatically 4. Auto-scaling cannot be restricted to one way-only, it's behaviour cannot be configured in any way 5. Legends, palettes and tools do not fit together to form an organized user interface, nor are they possible to detach from eachother to get more flexible designs/scaling for ecxample... 6. XY graphs become sluggish and almost unusable with large data sets, where alternatives written in other languages have no performance issues 7. Plot colors could automatically adjust to the chosen background color - suggesting unique colors for the added plots that provide the best possible visibility.
8. Graphs on e.g. Google and Yahoo have tonnes of cool features like animated zooming, thumbnail graphs, highlighting of the plot you hover the mouse over etc. which provide a very interactive feeling, you can achieve some of this in LV as well, but it could/should be possible with little or no programming
9. To get charts to accept data with variable sample rate (delta X) is possible, but cumbersome and an almost hidden feature...
Mixed signal 1. You cannot set the group names programmatically 2. The number of plot areas is not configurable at run-time 3. You cannot assign plots to a given group programmatically 4. You cannot show the visibility checkbox of each plot etc.
And then you have the additional 2000 ideas...;-)
As for front panel scaling there are not that many ideas (naturally), but the impact/value of them would change every LabVIEW programmer's life significantly. We can stop spending so much time finding ways around limitations in LV, and start focusing on the actual goal of our applications.
When we have multiple Enum values using a same case it is difficult to see what are the values using it. It would be good if we have a Tip strip showing the values handled in that particular case would be more meaningful instead of having "Selector Value" as a tip strip.
There is also an idea on removing the tip strip totally and it got fair response.