LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
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!

Post an idea

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?

Browsing through menus to replace a numeric conversion node is tedious.  How about allowing the selector tool to select from a pull-down menu, just like it does from an unbundle by name node?

 

Existing unbundle node behavior is shown at left.  Desired numeric conversion node behavior is to the right.

 

Quick_changing_of_numeric_comments.png

Hi,

 

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:

 

Array_ordinary.png

 

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:

 

Array_loop.png

 

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):

 

Array_more.png

 

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.

 

Cheers,

Steen

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.

 

24498iD9D667DE43F77BE8  

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 Smiley Happy

 

abort_all_running_vi.png

 

 

Hi guys,

I'm missing some very fast way how to create cluster out of selection. It could be done as it is shown here:

 

create cluster.png

 

I think since LV developers became familiar with Every GUI Programmer's Dream they are ready for the next step...

(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[4] 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. 

 

color.pngcolor.better.png

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.

 

CurrentForLoop.png

 

Here's an example of the new lower-profile For Loop with the unnecessary terminals hidden:

 

LowProfileForLoop.png

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.

 

Numbered error case.png

Preamble:

Just following up on a sub-idea raised within this recent idea from tst: LabVIEW should break VIs which have hidden code.  I *almost* like tst's idea, but IMO it is a bit too heavy-handed:

  • YES, I want better information when there is hidden code on my diagram, but...
  • NO, I don't want my code to break!

 

The Idea:

If a structure hides code beyound it's boundary, then provide a visual indication. For example, the edge of the structure could be coloured red to alert the user that something unexpected is going on.

hiddenCode.png 

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:Modal.png

 

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.

 

 

  It would be very usefull to know which VIs are still running.

   aaaa.png

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!

 

In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.

 

Here is a simplified example to illustrate the problem (see picture).

 

 

In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.

 

However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course Smiley Happy). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!

 

What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.

 

The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.

 

Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.

 

(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)

 

Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

There seem to me to be a couple of choke points in right-click access to VIs and functions.  One is that I frequently need to use the same VI's repeatedly.  Another is that the quite useful "insert" and "replace" context items only offer a few first-tier options: one or two related palettes, or all palettes.  Try to insert a few datalog functions for example, and you have to navigate down 6 levels for each. It's even worse if you have to use "select a VI..." and browse to it. For the worst cases, insert and replace lose their advantage over copy-paste or quick drop.

 

 I propose a dynamically generated palette consisting of the last several VIs and functions (even controls) that have been dropped.  This is analogous to recent-commands-list functionalities common in CAD packages.

 

- As a member of the functions palette, the items in it are at or above the level they are in their normal place in the hierarchy.

- Since it's a palette you could pin it and it would be handy for dropping the same node on two different block diagrams

 

 

recentVIs1.png

recent_replace.png

I would love to be able to draw a box over a bit of code on the block diaghram and be able to highlight execution just for what's in the box. The rest of the code should execute at full speed. This frequently becomes an issue when you are trying to track down a bug in a big program and you've got to wait for ages to get to the bit your interested in.

I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:

 

 Case Insensitive Equal.png

 

It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):

 

 
Case Insensitive Equality Comparison.png

I use the conditional disable structure in my projects to turn debug options on and off.

At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.

You can get around this by automating you build but an option in the build specifications would simplify this.

 

It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

 

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

I could be easier to insert or delete element from array by only select and hit Insert or Delete on keyboard.

 

Insead of this:

 

DeleteFromArrayOld.png

 

Select like this:

 

DeleteFromArrayNew.png

 

 

Title says it all. Have a slider or pull-down that increases or decreases the highlight execute rate.