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!
The recently introduced Raspberry Pi is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).
The Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 15 times the processing power!
Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?
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.
Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog. The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu. I can't think of one time when this has ever been what I wanted out of this action. Instead, I think this action should open up the VI Properties Window for the VI.
If you are not using the Data Event Terminals in an Event Structure, you might customarily hide them - roll them up so that only one terminal is showing. I would like to hide that remaining terminal. The idea is to not grey-out the Remove Element option when you are down to one terminal. That way, you can remove it. A stub remains to right-click on in order to bring the terminal(s) back if required.
There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs
It would be nice, if the different kind of LabVIEW windows would have slighty different icons within the windows taskbar. It would be easier to quickly identify BD / FP / project / Ctrl / etc. windows in the taskbar.
Resizing the front panel so it is correct when running the VI is still very tedious and can easily mess up during editing. The problem is even more severe for Xcontrols, because their runtime size is often very small so there is not even enough room to e.g. display all the tools in the tool bar during editing. Once the runtime size is correctly set, all it needs is a double-click on a terminal that has its FP item hidden outside the visible area and everything on the FP shifts and messes up.
We need three things:
An "edit time" FP size that is "comfortably big" so we can see the entire toolbar and possibly also helper controls and even maybe some comment text intended for the programmer that are outside the operator area and only used for debugging and such.
A "run time" FP size that matches exactly what the operator sees during running.
A special decoration or other visual cue during editing that indicates the FP area that will be visible at runtime.
We already have the crosshair in the upper left corner when showing the grid, so that could be defined as the upper left corner at runtime by default. All we need is define the upper left and lower right corner and the runtime FP area is uniquely defined. As a visual cue, everything outside the runtime area could be a shade darker or tinted differently than normal to indicate that fact. Running the VI would snap the FP boundaries to the bright area.
Then we also need handles to move any of the boundaries at single pixel increments. A control that scales with the front panel would simply scale to the bright area instead. Of course a legacy mode for older VIs that did not have this feature during their creation needs also to be supported.
The example image shows a reddish transparent area (just to throw out another idea, maybe a slightly darker grey would be better). This is one of my own subVIs that demonstrates the problem at hand. At runtime, only the progress bar should be visible, while at edit time, I want to see all controls, because I might need them e.g. to wire the connectors. It is not easy to switch between the two sizes.
(Of course we can currently program around all that by setting windows parameters via property nodes, but it is ugly, inefficient, and tedious.)
This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.
To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.
Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. Theydon'tevencarewhatwasusedtodeveloptheprogram.There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.
My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.
Typical phone exchange yesterday:
me: "just click my installer and install the program"
him: "OK, done."
me: "now run it."
him: "OK, ...... error about 2013 run-time engine".
me: "OK, install the run-time engine using the link I sent you in the same e-mail".
him: "clicking the link to go to the run time engine page....
(..30 second discussion to decide between downloader and direct download...)"
him: "click..(wait for it!)... .it wants me to register..."
me: "OK, let's forget about that. come down to the lab and I will do it for you."
End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.
While gazillions () of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.
I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to " I don't want to register at this time, just download the run-time!".
Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers.
(As already hinted here, I think this deserves a seperate idea).
Property nodes have many items that accept color data (cursor color, plot color, bg color, etc). When right-clicking these and "create constant|control|indicator", we get a generic U32 type. Instead, we want a colorbox! Even more complex color structures, e.g. (colors of a boolean) should have colorboxes as the innermost elements.
In all instances I have ever used these properties, I ended up replacing the U32 with colorboxes for code readability and simplicity.
Idea: when creating an input or output (constant, control, indicator) on any color property, we should get a colorbox (control, constant, indicator) instead of a plain U32 numeric.
When you connect the error wire to a case structure selector, you get two cases for error and no error. I think you should be able to add in cases for specific error numbers so you can handle specific errors differently. You could do this currently, but you would have to unbundle the error and use the error code.
I often make small For Loops using Auto-Indexing, and only occasionally do I use either the Iteration Terminal or Count Terminal. My current practice is to tuck the Iteration Terminal under the Count Terminal just to get it out of the way, shown below. I propose that these two terminals can be shown or hidden (circled in green), just like the Conditional Terminal.
Here's an example of the new lower-profile For Loop with the unnecessary terminals hidden:
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.