LabVIEW Idea Exchange

Community Browser
Top Authors
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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:




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.




 When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls.  The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
Workaround:  Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons.  However not as convenient.



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.




The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.


Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!



Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.


The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??


Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.


As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.


Idea -->LabVIEW should also standardize here!




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 🙂





The title says it all: The property dialog of controls should allow inspecting and changing the default value.


Here's how it could look like.



Sometimes I wand to re-define a default value without actually changing the current value.


current steps

  • copy the current value elsewhere
  • enter the desired default value
  • operations...make current value default
  • restore the original value (could lose data in case of DBL!)

After implementing the idea

  • default value...OK.





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.


LabVIEW needs native SSH and SFTP connection support. 


In the past, LabVIEW users have had to rely on third party applications like PuTTY or ExtraPuTTY to do very basic Linux/Unix secure shell operationsNot only does it add an extra layer of complexity to the code but it is also quite inflexibleIncreasing interoperability requirements of present day (and future) computer systems rely heavily on terminal services with a vast percentage of those being SSH basedIn the past 5 years I have needed to use SSH type connections more and more inside of LabVIEW, I do not see it ending anytime soon and I know I am not alone.


An SSH connection could be managed in much the same manor as the current VISA and TelNet connection are managedAn example of some of the tools could look something like the below image and could come standard or part of the Internet Connectivity Toolkit.



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.

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

Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:




The current process of moving one of these elements:

  1. Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
  2. Wire to the new element, and deal with deleting the old wire
  3. Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu

This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:

  1. Context menu with a "Move Up" and "Move Down" action (not so elegant)
  2. A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
  3. A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)



Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.

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





When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.


Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.


After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.


Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.


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

Currently text in an "unbundle by name" node is centered. This makes for poor readability when there are several elements being unbundled.




I think that changing the justification from center to left does improve readability.


Left Aligned.png


Note 01: This apply to bundle by name as well.

Note 02: implementing this idea my gave us this one for free.

I started a discussion here


Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project.  I never use the default icon provided by NI.  -- N-E-V-E-R --   That's a personal choice. 


So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless.  Let's see how many users of LabVIEW also find the default icon useless....  (Kudos would be a way to take a poll).


A nice feature would be to allow the developer to create her / her own default icon.  The default icon is probably somewhere in the ini file (I have not checked).  One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.


In my case, when creating a new VI, it ends up with a icon like this:




I would be happy to have a default icon that looks like this:




The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.


And may plenty of kudos adorn this thread..  🙂




I would be surprised if this is not a duplicate but I was unsuccessful finding it.


The subject says it all. Simply add a scrollbar to free text labels. I sometimes use a string constant for free labels simply because they can have a scrollbar.




                                            "Build Path" should be Growable


                              something like this,




Digital display Misalignment.png

Digital display Misalignment solution.png


In the old days the digital display was automatically aligned with the plot legend (if I remember well). Now it is by default not.

It takes some manual alignment actions to get them right. But don't resize your chart!! You can start all over again.


I propose the option to align the digital display as shown in the last picture.


(BTW, looking for duplicates I found one comment in