NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

Let the user choose the probe location on a wire

Status: New
by Active Participant X. on ‎04-24-2015 08:13 PM

Ther are 10 pages of suggestions coming up when typing "probe location on wire".

AFAIK, none of them addresses this irritating behavior of probes:


Screen Shot 2015-04-24 at 18.07.18.png


The probe icon will snap to some algorithmically determined location which might result in illegible data flow during debugging, or might end up in a region of the diagram far from where the critical action takes place.

I know that what matters should be the VALUE of the probe, but WHEN to check the probe value is also critical, and in a visual development environment, this time is determined by monitoring the data flow (among other methods). This is where this uncontrollable probe location can be annoying at times.


My suggestion: just as for labels, let the user choose the location of a probe anchor point on a wire (especially when it branches off).

Option to open VIs or projects for viewing only ("locked" or "read-only")

Status: New
by Active Participant SFK ‎04-22-2015 08:57 AM - edited ‎04-22-2015 09:06 AM

When reviewing old projects or VIs, the "VI changed" title bar star is always only a few mouse clicks away. And beware of accidentally opening an old project with a newer LabVIEW version!


You all know the "vi has unsaved changes" dialogs that follow when just wanting to close the windows, and who has not at least a dozen times saved an old VI in one of these situations just out of a misplaced click or the habit to save your code whenever you you are prompted to...



This is why I propose a new file menu entry: open (locked)... or open (read-only)... or an "open options" control in the file dialog.


Its functionality would be to open the selected file or project in a similar way like the locked VIs: you can look at them, browse through case or event structures, but cannot change a thing...


Even better would be the option to allow changes (e. g. move/delete some portions before selecting the rest for copy&paste), but to prevent re-saving the file under the same name. For this case, trying <CTRL-S> or closing the file would open a dialog stating that the VI was opened as "read-only" and that you may either discard the changes or save the file under a new name.


Of course, this "read-only" flag would be inherited to all subVIs, typedefs etcetera that would be opened from the original project or VI.


And to make my whishlist complete, a color coding of the VI window / project frames would signalize the read-only state of the code:



By the way: Wouldn't it be nice if VIs in vi.lib featured this opening mode by default?


Best regards,



Do not let wires pass between terminals

Status: New
by Member LukeASomers on ‎04-21-2015 05:18 PM

When wiring a VI, a cardinal sin is to put nontrivial wiring behind the VI icon. I see no use cases for this invisible wiring, and it directly causes many errors. In particular, accidentally wiring up the output of a bundle operation to the 'cluster in' box, so the bundle operation is completely ignored, yet the code looks perfectly OK.


This would be very easy to prevent. Help us not do things like that by letting us enforce the constraint:


When wiring or moving VIs or other structures, enforce the constraint: wires cannot cross the line separating two terminals.


By 'lines separating two terminals' I mean any of the interior lines on the wiring diagram that have at least one side being a valid terminal. For instance, I've marked in red the places wires should not go (using the terminal diagram, even though you never see the terminal diagram on VIs on the block diagram)





If you do something that would cause such a wiring abomination:


Check to see if the wire simply crosses the border and then crosses back (a common case). If so, cut off the part that transgressed and connect the two  severed ends inside the terminal.


Otherwise, push the offending wire out the side of the VI. If this movement causes it to cross a boundary in some other VI, introduce a wire bend halfway between and solve the halves independently. If no solution can be found - VI's are on top of each other, say, complain bitterly (red X on wire).


Only enforce this constraint when editing (such that you're creating the problem), not when reading the code. That way, noncompliant code is not broken.



Close Project

Status: New
by Trusted Enthusiast on ‎03-21-2015 02:03 PM



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


 Getting a value change event on a shared variables seems to me like something that ought to be expected "out of the box" in LabVIEW.  Polling shared variables for changes is taxing on resources, and such an architecture is generally frowned upon by NI and the LabVIEW community for things like front panel interactions and the like.  Why, then, should we expect to pay extra to deploy applications which such an architecture for interacting with shared variables?


I completely understand the extra license for the DSC run-time, as there are numerous other terrific tools included.  It just seems to me that the SV value change events are one thing that should be freely available for deployment to everyone already paying for the application builder.



There are two undocumented events for arrays:





which are unfortunately lost when you replace the array contextual menu by your own.


They could in principle allow finding which element a user has deleted or inserted. Indeed, sometimes "OldValue" and "NewValue" are not enough to infer this information (think about identical values in an array).




The only additional information currently provided is "Coords", which tells where on the FP the user event was generated.

In principle, it should be feasible to get back to the location of the element involved and from there find out the element's index, but add scrollbars, panels etc, and that rapidly becomes a project by itself. Moreover, you can "insert" a value to the end of an empty array control and the inserted element will anyway be "inserted" as the last element (which also be the first and only element).

In other words, after having carefully computed where the click took place, you will still have to figure more about the control itself to make sure all the corner cases are covered. Big PITA.


Instead, I'd suggest to have both events also output the array index (or colum/row, in the case of a 2D array (*)) where the event occured. This is a known information to LabVIEW, since the control is updated just fine.


Now there is still the issue that the insert and delete element events are accompanied by a synchronous "Value Change" event, but that can be dealt with in a rather simple way (as long as you are aware of it).


So in summary, my suggestion is, as the title indicates, to provide an "Array Index" output for the "insert..." and "delete element from array" events


(*) Notice that there is no such shortcut event for array with higher dimensions...

Right now - Requried Terminal is identified by either 1. Bold text in Help window 2.Broken arrow.


Will it be posible to highlight / mark the required terminal, so to identify at first look ? Something like mentioned below.


VI.PNG           zoom.png zoom3.png


Sorry i couldnt draw properly. but some thing like this to highlight both in FP and BD.


Event Structure (event data node)

Status: Duplicate
by Trusted Enthusiast on ‎04-22-2015 04:48 AM


                                The event data node does not retrurn "all elements"


             it would be nice and useful if "all elements" would be also available






                                                                                        like this;




Wire : Right Click --> Visbile --> Label  (Its void Now )


1.png                                  2.png


Solution : It can take the control Name as default label of the wire,  instead of  being Void





Not sure if this idea is already proposed. 



Index & Bundle Cluster array should retain element names

Status: New
by Knight of NI ‎02-13-2015 11:31 AM - edited ‎02-13-2015 11:32 AM

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


Event Timeout Terminal (Event Structure)

Status: New
by Trusted Enthusiast on ‎03-14-2015 06:23 AM


                  A picture's worth a thousand words












Include longstanding "known issues" in the help file

Status: New
by Active Participant X. on ‎03-09-2015 01:17 PM

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.


My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

Add Control Anchors to Labview

Status: New
by Member ngarneski on ‎02-11-2015 02:44 PM

.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors.  Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:



Would be resized into:



Lock text in center

Status: New
by Trusted Enthusiast on ‎04-13-2015 01:13 PM


                                                           "  lock text in center  "





                                        ... sorry ..  but the text is not in center


                  A > B , and the difference is greater than one pixel




Add an option to remove items in memory

Status: New
by Active Participant dsavir on ‎03-30-2015 02:41 AM

After deleting items I don't want in the project, or loading plugins in a  plugin architecture, I want to remove them from the LabVIEW memory. This is not possible now, as they go into Dependencies->Items in Memory.

Items in memory.PNG

The only way to do this now is to close and open the project, which over a large Plug-in architecture project is a real pain. 

Ideally, I would like to right click the folder and choose "remove from memory". However, any option that allows this would be good.


Thank you!



remove thick wire corners under Select block

Status: New
by Member Enrico_Segre on ‎03-10-2015 05:19 AM

Aesthetic issue: thick wires connected to Select inputs show as ugly corners behind the triangle icon, probably a result of the underlying connector pattern.This does not happen for other triangular blocks, at least not up to a reasonable wire thickness (to make a wire thicker, just make a N-dim array of something).


Snippet Palette in Block Diagram

Status: New
by Member sandyy on ‎03-24-2015 10:58 AM

Populate all snippet captured in function palatte for reusability



Problem: my code accesses many different properties of many different controls. I need to locate where a specific property of a particular control is read/changed.




I know that the Find panel offersi me the option of searching by text, like


Screenshot from 2015-02-01 13:46:10.png

but that is not the solution, because I need to type thename of the property, and because I may match many other objects with the same string (comments, other controls with the same property, etc.)

I'd like a faster way to get to where I need. For instance the contetual menu could offer Find/specific property according to where the right-click was.

Comparison Palette Better order

Status: New
by Active Participant Manzolli on ‎02-10-2015 06:17 AM - last edited on ‎02-10-2015 09:39 AM by Trusted Enthusiast

Very simple idea that can make locating the basic comparison functions more efficient (first two lines). Changing the order putting each comparison function and his counterpart below him would make easier to find the desired one.


Now: Comparison palette.png        Proposed: Comparison palette - rearranged.png

Latest LabVIEW Idea Exchange Blog Posts
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
User Kudos Count
Idea Statuses