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´d appreciate an event that is called whenever there is a change of Top cell (row). Several times I needed to "align" visible content of two objects (listboxes, trees, etc.). Value change or mouse scroll event can be used but still I´ve found no way how to catch when the user uses scrollbar arrows or draging scrollbar position indicator. The only solution I found is to keep it aligned by periodically reading out Top row visible property of one object and set it for another one. That requires code in Timeout event that is called very often (otherwise it is noticeable for user) causing performance drop.
When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:
Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:
To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):
The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.
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.
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.
When using Typedef's I often have teh control wire passing through a VI. If I need to modify the typedef, I have to either create an instance of the controil/indicator, or got to a VI that uses the typedef control and the righ-click. From here I can open the Typedef.
What I would like to do is to be able to right-click on the wire and select directly 'Open Typedef' without having to go to a control.
It is a minor issue, but if I am in the middle of development in a VI, I don't want to have to click away from the VI under development to find the control. Additionally, creating a constant so that I can right-click on it is also not so convenient. If the Typedef is a large cluster, the block diagram may be distorted when the Typedef appears.
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 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.
According to some engineers that I have spoken to in the prototyping industry, Windows 10 IoT is gaining some traction as a preferred embedded OS for developing ideas. Windows 10 IoT, as I understand it, is delivered in 3 different versions: Core, Enterprise, and Enterprise Mobile. Now where Core is built as a .NET application and lacks some of the system capabilities of Windows 10, the Enterprise version is built as a Win32 OS and is closest to Windows 10 as it is now.
If resources allow, it might be beneficial to see some future support for at least this version of Windows 10 IoT to meet the demands of a growing body of engineers who will want to integrate LabVIEW executables with their Windows 10 IoT powered devices.
Languages like 'R', 'Python', and MatLab (yes I use the old name) have these. They are useful.
One of the key ideas in LabVIEW is that the user needs minimal interventions to code a useful result. As more information is encoded in a data type there is more opportunity to make "hands free" code that "just works". I think these two data types can do that.
Primary data type in R
It is Array-like, but NOT an array
each column contains one measurement (row) on one variable
It acts like a list of vectors, but the vectors have the same number of rows, and indexing allows a return of all or subset from all columns
column types are heterogenous - they can be different
column types can be set. A column of 0 vs. 1 can be set as factors/binomial values or as continuous.
There are functions that data analysis folks do every day that are informed by variable type, so the function operating on the inputs doesn't need type specified because it is interior to the table. This means you can say "plot(mydata)" and if your data is set up well, the graph parameters are already specified and useful.
This is from Hadley Wickham, a very famous person in 'R'. He does great work, and his name has high brand value in data-analysis.
Uses the "data.table" package
is able to be screaming-fast (think roller-coaster) especially when used with the "split-apply-combine" approach to data analysis, and SQL-like operations.
is built for handling huge data (100GB tables) quickly and efficiently.
In many applications the same operation is not possible due to memory constraint or viable due to processor overhead can execute adequately (aka wonderfully) by using this data type on the same hardware.
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!
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.
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.
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.
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.