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

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

Break bad wire branches, not the entire wire!

Status: New
by Knight of NI Knight of NI ‎09-11-2015 05:01 PM - edited ‎09-11-2015 05:14 PM

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.

99% of the time when I use a Diagram Disable Structure, I am disabling code with an error cluster wired through. I don't want to lose the errors coming in, just the single operation, so I manually wire the error cluster through the empty case each time.


I've talked to others in the past about this and it would be nice for LabVIEW to be all-knowing and wire all datatypes through that match, but that would definitely lead to conflicts and mistakes. Error clusters, on the other hand, are simple are nearly always a single wire in and out.

Simply auto-wiring the error cluster input to the output would make the debugging process much easier.


Code with disabled operation:


Referenced Comment

Status: New
by Member PTschepe on ‎09-25-2015 05:15 AM

It would be useful to have something like a referenced comment. You can place this comment in the block diagrams of several VIs of a project, and by editing one instance of this comment, it will change all instances at one time.




The comment describes the channel list of an application:



AI_00: Torque [Nm]

AI_01: Pressure [bar]

AI_02: ValvePosition [%]



You place this comment in the DAQ-VI. But it would be helpful to have the identical comment in the MeasFile-VI and/or in the VI that combines the channel and scaling informations to a 2D-string array, so you can present all these informations together (e.g. in a multi cloumn list box or something else).


When you later add some new channels e.g., it will be annoying to edit all these comments step by step, something like a 'comment type def' would be a practical solution.

Autoscale Only When Go Outside Scale Range

Status: New
by Member thesnarfman on ‎09-16-2015 01:14 PM

Want to have graph display a certain scale unless values go outside scale min or max and then do autoscale but only in direction which scale bounds were crossed.

Normally want graph to display X scale 0 to 10 to display to user:
Scale 0 to 10 look good.PNG
If set same graph to autoscale would get the following graph that user could interpret as values are swinging all over the place but this could just be noise and I do not want to display this format to user:
Autoscale Bad.PNG
So I want a solution that incorporates manual scale and autoscale by autoscaling only after scale limit is exceeded. Asume get a data point of 13 which is above the max scale range of 10, graph would do a single autoscale only in direction above 10 to change max to 13.
Desired Result.PNG
Would be Graph Scales property. Option disabled if Autoscale was selected.

I know can use property nodes to programatically do this in my program but it is much more involved having to constantly check to see if values have gone outside range and then issue a single Autoscale.

I know hyperlinks in free labels have been implemented in LabVIEW 2015 and that the idea has been marked as implemented:


Kudos to that and I love it. 


However, there was another idea:


that was closed as a duplicate of the hyperlink in free labels, except there is a small difference in the second idea that was not really implemented. The hyperlinks do not let us insert links relative to the project, the poster of the Documentation links on block diagrams even says: "The risk would be moving the document and the link becomes invalid. This risk could be minimized by placing a documentation folder in your labview project." 


So this new idea is to let us either use relative paths on the hyperlinks on the free labels: i.e. file:///C:/ProgramData  or use environment variables such as %userprofile%, %programdata%, etc. For example, file:///%userprofile%/documents. This would make it possible to put links to documents in our machine that will be in a different path than the rest of the team working on the project. The documentation might be relative to the project file, but might not be exactly in the same location in each machine due to differences such as %userprofile% = C:\users\<user name>  where <user name> will be different for each team member. 



rotate decorations

Status: Duplicate
by Active Participant WNM on ‎09-28-2015 10:08 AM

I would like to have the ability to rotate front-panel decorations like rectangles or ellipses to arbitrary angles.




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



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



Event Structure: Configurable timeout terminal

Status: New
by Member MGiacomet on ‎08-20-2015 08:18 AM

Tired of resizing an event structure and having to relocate the timeout constant?... Simply double-click on the hourglass and type the timeout value!


Of course, the option of wiring to the event structure timeout input should still exist. Just like the timed loop, where you can double click and set the period, etc.




Make Search Results Position @ Center of Screen

Status: New
by Member Mr._Bob on ‎09-16-2015 09:40 AM

When selecting block diagram items from the "search results" screen, the resulting highlighted area on the block diagram always seems to be on the extreme edges of the screen. This requires a finite amount of time scanning all four corners of the screen for the item. Recommend that the "found" item always be positioned in the exact center of the screen to eliminate this issue.



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

Status: Completed

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.


Make the VI's from the "vi.lib" Read-only

Status: New
by Member heiner1 on ‎09-11-2015 09:53 AM

I believe many of you had already the problem that you accidentally changed a VI's from the vi.lib  and saved it.


There should be an option to use the complete vi.lib Read only!
I do not want to change the VI's in the vi.lib at all! Never!


Thanks for your support.

Excuse for my bad English.




Sample of an open VI from the vi.lib




and in the Options Menu it can look like this:



update value within array of cluster

Status: New
by Member r_exler on ‎08-31-2015 10:17 AM

Updating a value within an array of cluster is too complicated compared to other programming languages.


In my application I hold an (global) array of jobs to do, each consisting of its name and an array of (different) parts belonging to this job. One element of the part's description is the number of parts already done. If I want to update this value, the code looks:



Note the calling function has to update the global variable after updating or JobFilesIn and JobFilesOut can be replaced by reading/writing the global which does not make the code more visible.


Within C code the update would look


which will not raise the need of making it a function (VI) at all.


A solution might be similar to Replace Array Subset if the compiler is parsing the data type on the input and accepting indices and cluster element names as shown below


Of course this should work with any data type selected from the initial variable by the selectors similar to C code




It also should accept a cluster as top level element as well, e.g. to replace an element within an cluster of clusters similar to C code



or an element within an array which is part of a cluster.



All the C code examples above expand to LabVIEW code which is hard to read.


 which it is still not doing in LabVIEW 2015.

An RT program can be ran either from a host PC (what I call the "interpreter mode"), or as an exe in the startup directory on the RT controller. When running from the host PC (for debugging purposes), it allows front panel "property nodes" to execute properly as you would expect. After building, and transferring to the RT app to the startup directory on the RT controller, the program errors out on the first occurance of a front panel property node. The reason is obvious; a front panel is non-existent in an RT application, hence the front panel property nodes are rejected. Of note, no errors or warnings are generated during the RT app build operation.


Recommend that the build application simply ignore the front panel property nodes as it ignores the front panel in general. This would allow the programmer to retain the same version of the source code for either mode of operation.




Resize Rearrange Cases window

Status: New
by Member pawhan11 on ‎08-20-2015 10:41 AM



Could You allow to resize Rearrange Cases window? 




By default it fits only 8 cases and it is hard to move and work with it when we have to rearrange 30 or more...

Other idea is to select many cases by holding Shift

Silver Error Cluster Boolean

Status: New
by Knight of NI Knight of NI on ‎08-03-2015 10:22 AM

I have a Red-Green colorblind coworker.  When he looks at the Silver Error Cluster, he actually cannot tell if there is an error.  Why?  Because NI decided to make green the false state and red the true state of the boolean.  So he updates his error clusters to use black for the false state.


Simply put, that boolean display needs either icons (like in the Modern Error Cluster) or different colors to help these people.

undo steps

Status: New
by Active Participant PaulG. on ‎09-28-2015 12:56 PM

Sometimes I swear I do more to a vi before I start ctl-z to undo steps. I think it would be handy if when you run out of undo steps a little popup window pops up and says: "all steps undone"


LV currently allows you to swap wire positions (on BD) or terminals on the connector pane just by clicking on connection point while holding Ctrl key.

So why to not implement this also for the Case Selector Terminal?


Then you would be able to wire Case Selector Terminal in two clicks:




Of course swapping cursor will only appear if you select terminal that is considered as compatible/valid input of the Case Selector Terminal (based on auto-proofing which will exclude arrays clusters images, references and so on).


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