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 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 current implementation of Control References on the Block Diagram could be improved. This Idea was first conceived over a year ago in a discussion on Smaller Static Refs, in the comments here.

 

21816iB89689857FFA076E

Consider the following advantages:

 

  1. It's generally bad style to have Ctl Refs with hidden labels. New implementation always demonstrates the label to comply with inherent self-documentation of G (just like a Local)
  2. Smaller footprint combined with better visual distinction between Ctl Refs doubly improves information density
  3. In general, the Control Class does not need to be shown at all times on the BD. Rather, it could be shown in Context Help (currently, CH is not useful when hovering over Controls Refs, but this is another topic), or determined by browsing Properties/Methods.
  4. Eliminates the undesirable ability to rename/delete a Control Ref Label such that it no longer matches the Terminal Label.
  5. Creates a better distinction between a Control Ref and a Control Class Constant (NULL Ref). The color of the Static Refs denote a "live link" with a control, while the muted tones of a Class Constant indicate no such link (NULL)
  6. Complements the new LV2010 Local Variable upgrade (see image), yet remains distinct by having a different glyph, different background colors, and no directionality arrow
In summary, a Control Reference revamp could reduce the footprint, increase readability, and prevent obfuscation that decouples the Static Control Ref from the Control.

I have a rather large string indicator for displaying operator messages/alarms

and I would like to have the option for an automatic vertical center of the text,

so that all messages get displayed in the center of the screen (if too many lines, justify to top and display the scrollbar).

I also have a 2 line statusbar, but displaying a 1 line message that is not vertically centered, looks very strange.

 

The work-around I'm using now is to display the multiline string centered in a picturecontrol,

but I'm not a big fan of this fix because there are many boundary-conditions to keep in mind ...

 


 

Another annoyance is that to prevent selection of text in the indicator I often disable the indicator

(it looks unprofessional if an indicatortext can be selected in the GUI),

but if the displayed text is larger than the string indicator, the scrollbar is also disabled !?!? 

and therefore not controllable by the user

 

I am probably not alone in my trepidation in using the Block Diagram Cleanup tool, but I can not help but recognize its power to be a tremendous help.   We already have tools (Grids, Align and Distribute, Ctrl-T QD shortcut, etc.) to get Nodes and terminals positioned nicely.  Even with this idea in Beta, wiring can still be a tedious chore.  The BDCT does a reasonable job routing wires, but also moves things around including control/indicator labels, and is often unsatisfying.

 

What I want is to be able to lay out the BD, wire things while only worrying about beginning and end, and then have the BDCT only adjust the wire routing.

 

Despite numerous RCF shortcuts and new behavior in LV10, this is not the same as cleaning wiresThe solution is not to methodically select only wires and Ctrl+U.  The reason:  the process should be a global optimization, not a serial process where each wire route is chosen based on the current state of the BD.  The BDCT uses a global optimization, 'Cleaning wires' does not.  What I want is the optimization of the BDCT limited to only wires, leave my nodes and terminals and labels alone!

 

For example see the following:

 

RouteWires.PNG

Right now, if you happen to use the right colors, LabVIEW will change the text color on a Boolean.  But, if you don't pick the right colors, LabVIEW keeps a single text color.

 

Boolean Text.png

 

 

This would probably be fine IF LabVIEW allowed you to have multiple text colors, but you can only choose one:

 

Boolean Properties.png

 

But, as you can see, LV only supports one text color.  I propose that LV support two text colors (ON and OFF).  Obviously LabVIEW has the ability to change the color already since it will do it in the right circumstances, but it would be nice if LV gave us control over it.

 

In my use case at the moment, I am trying to make a custom illuminated button which the text on the button should be grey went off, and yellow when on.

The venerable Array Size function should just resize itself for the number of dimensions on the input array and have each dimension's size emitted with a separate scalar output.

Unlike the scales of numeric controls, graph scales don't support text labels (wouldn't that be cool! :smileywink: ) *(see footnote)

 

It could be handled very similar to the way text labels are handled for the scales of numeric controls, so most of the code is already there.

 

This would come in very handy for e.g. histograms or bar graphs, where each bar needs a text label, or for cases where we have arbitrary units.

 

Examples for integer scales: 

  • "January", "February", ...
  • "LabVIEW users", "CVI Users" ...
  • "Europe", "Asia", ...

 

Examples for floating point scales (x, or y):

  • "Too cold", "cold", "warm", "hot", "too hot"...
  • "small", "medium", "large", ...
  • "min", "max"...
  • "high frequrency", "low frequency"...

 

*My quote from this old discussion . See also Ben's example further down.

 

 

Problem:

I faced to delete multiple elements form the array which is having 20 steps.

 

solution:

if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.

 

 

Array element.png

 

 

(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.

 

Even though I use the tools selection in the automatic mode, many times I need some specific tool not accessible in the automatic mode or force one like "Position/Size/Select". Sometimes, mostly designing User Interfaces (UI) that takes all screen, we got the Tools Palette blocking access to something. Then we move the Tools Palette until it get in front of something else.

 

The idea is to have an option to have all buttons in the toolbar. Some programs allows you "dock" just dragging the over the tool bar.

 

Many times we have plenty of space to have all buttons there, if not, we can have a second row of buttons. That will be nice to add more buttons as we wish.

 

tools palette buttons in the toolbar.png

 

PS: I added a swap button between the foreground and background colors. The idea is explained in this thread Swap Colors in Tools Palette.

When I have an array of clusters and I want to locate the array index where a specific element of the cluster has a certain value, I need to first build an array from the Array of Clusters and then search that to find the Array element I want:

 code example.jpg

 

It would be nice (and cleaner and likely faster) if I could wire the Array of Clusters into an unbundle by name function and select String[] to get the array of string element to search.

In addition, if the cluster contained nested clusters, I could access them the same way, using the dot notation alrerady supported.  For example, the unbundle would let me select 'cluster1.subcluster2.String[]' to access the subarray of an element.

 

code example2.jpg 

 

 

I really hate having to dig through a long hierarchy of menus when I know what I want:

 

 

DrillDown.png

 

 

 

 

 

Visual Studio (and other MS and non-MS products) have a feature called Intellisense, which is meant to make this easier. Basically, as you type, it pops up a list of matching objects, based on context, so you can quickly select what you want:

 

 

Intellisense.png

 

 

 

 

It would be nice if LV had a similar feature - click on a property in the property node using the text tool (or Ctrl+click if using the auto-tool) and now you can type in the property name and you will get an Intellisense-like pop-up, which will have all the relevant properties.

 

Specific features it could have:

 

  1. It should know all the relevant names - full names with the hierarchy (Boolean Text.Font.Color), long names (Mechanical Action) and short names (MechAction). This could probably be similar to how Quick Drop handles shortcuts or they could simply appear as separate items.
  2. It should be context sensitive. If the class is Boolean, then there's no need to have Listbox properties in the list.
  3. It should match all the properties which include the search string (so "in" on a boolean would match both "Indicator" and "Strings[]") and only them.
  4. It should have the ability to use caps for acronyms (e.g. in the above screenshot you could use "BT" instead of "Boolean Text", similar to what appears in this video).
  5. It could probably also work on the invoke node, although there it's less needed.
  6. It could probably also be used to quickly select a class if you have a class specifier using the same basic mechanism.

This example (LV 2009) shows how useful this could be. You don't need anything installed. Just run the VI and start changing properties.

 

Caveats:

  1. It will only work on the last property in the node.
  2. It doesn't have the proper list of names and it doesn't implement all the features in the idea, as this is just a basic example.

 

Note - this is similar to this idea, but I think that it's much more usable. Also note that the second idea refers to a QDKS which ships with 2010, but that is far from perfect.

Have VI in the project windows behave like SubVI so when you CTRL + Double Click on one the SubVI FP and BD opens (and the BD is frontmost).

Probes are so useful for debugging, but monitoring them within the Probe Watch window can be a headache. I constantly find myself focusing back and fourth between Probe Watch and the code to translate a probe number to a position in the code. A solution would be to have the probe's value float just above the probe itself. LabVIEW already has a similar feature. When you use Highligh Execution wire paths display their current vaules, but using Highlight Execution is too slow and no practical for every debug situation.

 

Here is the issue as it stands today:

probe_watch_window.png

 

Here is my proposed new feature! :

probe_text_annot.png

 

We've all seen the demo that shogg did where he set the color of his splitter bars to the panel color so they disappear at run time, but what if the splitter goes over background controls that you want to persist between panels?

 

22583iA7F722F2038D69E4

 

It look slike the smallest i can have my splitter bars is 2 pixels.  I totally want them to show up in edit mode, but I'd like them to be 0 pixels wide in run mode (selectable, of course).

Hi,

 

Currently to replace something (for instance a node on the block diagram) you have to right-click and then select Replace... and then usually a lengthy navigation into the function palette or onto the disk with the OS file explorer.

 

Most often I already have a LabVIEW-project open, one or more explorer windows (opened at a useful context), and maybe also one or a couple of pinned sub-palettes - but I am not allowed to replace anything from these locations. I suggest that this will actually be allowed; that is: drag something onto the block diagram, and if you're enough on top of another object, then a replace-outline appears for you to drop your new object into. Here's an illustration for replacing something in the block diagram, but the same could apply to the front panel as well:

 

Replace.png

 

All the usual stuff should happen when you replace this way, as if you replaced through the context menu. For instance a prompt to save a VI that leaves memory, automatic update of a project's dependencies etc. Many ideas are submitted to this Idea Exchange to enhance the Replace context menu in different ways, but a feature as I'm suggesting here would improve my own workflow the most, simply because I already have much quicker access to my "replacer", through existing explorer windows, than going through the Replace context menu no matter how intelligently it gets populated.

 

Cheers,

Steen

I think the Array Element Gap should be sizable. This would facilitate lining up FP arrays with other items on the FP, or simply as a mechanism to add more apparent delineation between elements.

The size should be set in the Properties box, not by dragging the element gap with the mouse - that would add too much "cursor noise".

A new Property Node for this feature would complete Idea.

 

GapSize.png

I would like to introduce a little shorthand for creating numeric constants with non-decimal radix.  New constants should be able to autoadapt for radix, much like they do for type:  Drop a constant, enter '0x20' or 'x20' to get a constant with Hex radix (visible!), and the proper value.

 

In addition, it would be nice if automatic conversions would take place if radix specifiers are entered into (non-hex) constants (or controls).  For example, entering '0x20' into a numeric control with decimal radix should result in a value of 32 being entered (auto conversion).  Hex is an exception, obviously, because b and d are already valid.  The other radices have no such problem.

 

ConstantRadix.png

Yup,  Upgrading LabVIEW versions takes a day.

 

The "Process" today is:

  • Install from media
  • Configure the new LabVIEW.ini
  • install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
  • Mass Compile all them......
  • Fix palatte views... and import and mass compile User.lib\ for here.....
  • Sync glyphs on the icon editor (If the link works......)
  • Add VIT's
  • Add Project Templates
  • Mass compileVIt's and Templates
  • fix "Metadata.xml"...

.

.

Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

The concept of fluent interfaces using method chaining applied to a LabVIEW block diagram would be awesome!

 

When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.

 

Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!

 

LabVIEW-Idex-Proposed-Fluent-Interface-with-Method-Chaining.png

 

See the first comment for footnotes...