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 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!
Post an idea

This idea is an extension / alternative for this idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/give-decorations-a-label-property-to-address-and-modif...

You can give Kudos to both ;-)

 

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.

 

deco_property.png

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.

 

.NET Constructor Node actual select dialog

 

Common .NET Editors supports users with dot notation and text recognition. e.g. Visual Studio

.NET Editor.jpg

 

OK that is luxury and not necessary - but what about a simple filter input field like in "Edit Events" dialog?

 

Filter Edit Events

 

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.

 

 

NewBrowse.jpg

 

 

Cleaning up block diagram always mess up my intention on placing blocks then I prefer to manually move around my blocks.

 

1. When I to move a function block, I want its inputs and outputs to move together with it.

2. True visible grouping like in "powerpoint" with relative position fixed

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:

 

20779iD19E3A04FFDC0A31

 

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. Smiley Sad

 

 

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 am struggling with my Event Structure event list and the corresponding list of cases in the parallel consumer loop Case Structure.

Both have currently over 100 cases each and finding one or scrolling down to access the latest one has become painful due to the lack of a scrollbar in these lists.

For instance, here is the Event Structure list:

 

Screen Shot 2015-09-29 at 12.19.16.png

 

Same goes for the list of controls in a Local Variable (and other objects, I am sure).

There is no reason why such lists do not have a vertical scrollbar when that corresponding to a Enum do have a scrollbar:

 

Screen Shot 2015-09-29 at 13.33.30.png

 

Or is there?

 

Suggestion: All long pulldown lists should have a vertical scrollbar

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.

IMAG000.jpg

IMAG001.jpg

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.

 

probe.png

SR1.png

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.

(Inspired by this discussion)

 

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.

 

Hi!

Maybe this has been already requested elsewhere and I'm missing it....

but it would be useful to have a Wait (ms) with connectors for error in and out.

This can help keeping the BD clean...

Marco

18613iCF039EA34765F743

Here's how we currently make cluster element labels appear, and a proposed idea for improvement.

ClusterLabels.png

(This is different and less controversional than  this related old idea)

 

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.

 

Ship developer suite on NI USB keys

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.

Not so much an idea, as a wish/plead/rant:

 

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.

Would that not make everyone's day?

 

 

The problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.

As result - aligning to vertical compress caused steps in wires:

 

Screenshot.png

 

Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.

Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)

 

Not sure if it was already in Idea Exchange or not.

 

Andrey.

 

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.

 

TipStripCaseSelector.png

Please ignore if already suggested!

If You drag a tunnel of a loop, case structure or any other structure along the border over a corner, then

the connected wire becomes hidden behind the frame.

 

Sometimes, the wire looks alike it is connected to another wire instead - like in the example below.

I fell into that trap, because I've just seen the frame to the right and didn't expect, that the wire was

connected to the tunnel near the bottom.

wire_behind_frame.png

Wouldn't it be great to break up the wire with a 90° corner and place it in the visible area?

     wire_not_behind_frame.png

 

 

More similar situations like this are posted in this thread:

http://forums.ni.com/t5/LabVIEW/wire-vanishes-behind-frame-of-case-structure/td-p/3221167