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

Create events for annotations

Status: New
by Knight of NI on ‎02-02-2011 01:02 PM - last edited on ‎02-03-2011 08:58 AM by Active Participant Laura F.

It is a little know fact that cursor move events and annotation move events cannot be distinguished directly. They both register as cursor move events.


This seems like a design flaw that makes little sense. I suggest to create a set of annotation events that mirror the cursor events so there is no crosstalk between the two. The new event set could even include this idea.



0 Kudos

Upgrading from older versions

Status: New
by Member p1170 on ‎02-02-2011 11:59 AM

Give the user the ability to upgrade versions of Teststand or labview without bringing the test equipment down for several hours. Currently it is quicker to image the whole pc than install a new NI software version. Some of the software (from other vendors) we run has propretiary configuration and imaging isn't always feasible. I would like to be able to upgrade from Labview 8.6 to 2010 without stopping production, just upgraded from 8.2 to 8.6 and on 50computers, on a production floor, it was logistically difficult. It would be a while before I consider upgrading again, with the current setup.

BD Cleanup - Option to only clean up wires (and leave terminals, nodes, structures, etc. in place)

Status: New
by Active Participant dthor on ‎02-02-2011 11:50 AM - last edited on ‎10-12-2011 01:10 PM by Member srdfrn

I know there have been a lot of Ideas regarding the Block Diagram Cleanup tool, but I haven't seen this one suggested.


There should be an option to force Block Diagram Cleanup (CTRL-U) to only act on wires. Essentially it would be the same as selecting all wires, right-clicking and selecting Clean Up Wire.


Similar Ideas, but not the same:


I'm almost certain that there is a scripting method available to accomplish this.



When you have to work with multiple LabVIEW projects at the same time, you may point to a VI of the second project, or save a VI in the other project ... This occurs frequently when you have to work with a project template which you have to duplicate !


The problem is that your project works fine ! But you point on misplaced VI's !

The problem will only be seen when you have to give the project to someone else, or 2 or 3 year after the project completion, when you want to made some updates. And then AIE ! A VI is missing ! :smileymad:


It should be nice to generate an "Optional"  warning (Popup), when any user action (save, insert VI on front panel ... ) handles with a VI not located under the project path. 

This visual warning could be interresting to avoid this kind of error.



Icon on Taskbar when LV is minimized

Status: New
by Member Zilog on ‎02-02-2011 02:22 AM


it would be a great idea to choose an option to put a LV icon on the taskbar when LV is minimized (when running a program), also try to eliminate the 2 windows when open an running a "vi", with one is too enought ...

Thanks !!!

Macro VIs and Code Fragments

Status: New
by Member Lavezza on ‎02-01-2011 10:07 PM

I'm cleaning up some code that has a lot of stuff like this (much simpler sample code shown):


The loops are (almost) the same. The normal way to clean this up would be to create a subVI like the following:


But this has problems. (1) Need to create reference on the calling diagram (2) Reading and setting values by reference (3) Doesn't handle the third loop which has an absolute value. You could deal with #3 by dynamically calling a subVI or having a case structure with an input, but that complicates the design and doesn't make it as flexible (reusable).


What if we expanded the idea of inline VIs introduced in 2010. Instead of the compiled code being added to the calling VI, the actual G code is added with input substitutions and then compiled. The 'Macro VI' is replaced by the code inside the VI and the gray placeholder controls/indicators are replaced by the calling VI controls and indicators. This is different from the current inline implementation in that the macro code would be reading the controls/indicators/locals during each iteration instead of just getting the values when the subVI was called. (I believe that is how things are working now, correct me if I'm wrong).


To handle sections of code that might be different, we could add something like 'code fragments'. Here's an example:


The orange 'code fragment' gets replaced if wired. The inputs/outputs of the code fragment would have to match.


I realize there are issuse if the input controls/indicators have branched wires, etc. Just throwing it out there.

First of all, I know I'm going to get a heck of a lot of flack for this idea. I know how you guys hate changes or additions to core structures :smileyvery-happy:



State Machines and Abortable Sequence Structures are very, very powerful. In my opinion, their only downfall is the fact that they require two structures surrounding the code: a Case Structure and a While Loop (or sometimes For Loop) surrounding that. This takes up diagram space (albeit not an absurd amount) and it is annoying when needing to resize the structures. If you add more code (and are OCD about everything matching up on the BD grid like I am), then you need to resize 2 structures instead of one.


My suggestion is to create a new structure that combines these two structures. I believe that this new structure, if implemented correctly, will reduce the number of overused stacked sequence structures by providing a simple yet intuitive core structure that offers the same functionality with more power. This new structure will also make it easier for non-programmers to become familiar with State Machines and their power.


Here is what the "State Machine" structure would replace:

Abortable Sequence and State Machine.png      --->     becomes  --->            combined case and While loop.png


The S input is a right-click option "Enable State Machine Input" which acts as a shift register and also as the case selector for the state. If "Enable State Machine Input" is disabled, then the iteration terminal i is used as the case selector. The i and Stop If True terminals are shown in every case, and the Stop If True has the option to use default if unwired (False) through another right-click menu (you can see this icon in the 1st "Abortable Sequence" structure). In my example I used an enum as the input, but any valid state machine input would work (string, DBL, boolean, etc.)


This would not be a full replacement for the original architecture: sometimes there is code that needs to be run before or after the state, on every iteration. This new structure would not be able to handle that in a nice way (you'd have to copy the code to every case, and that's just silly).



So, what does everyone think? Where are the flaws? What parts do you like?


It would be great if you could create a comment that would stick to the case selector label in a case structure.  If this were implemented, in the screenshot the "5PLL" comment wouldn't fly off to a random place when I cleaned up the diagram, but would stay with the case selector, making the code easier to read.



Palette import/export tool

Status: New
by Active Participant Underflow on ‎01-31-2011 01:09 PM

Setting up LV2010 today, it struck me how nice it would be to not have to spend time dealing with the clunky visibility/option dialog/palette file hacks necessary to get back to the environment that I like.


How about a built in import and export tool for palette settings?


If I were interested in, say, customer engagement and seeing what users actually do with their palettes, I might even add web-based cloud hosting, so users can upload and download their own palettes wherever they are.

In LV 2010 the string constant display style is a nice new addition based on the ideas here and here.

The implementation is consistent with how the radix indicator works on numeric constants in that you must navigate to the visible items shortcut menu and turn them on discretely.

If I want to take a string constant, show it in '\' format and turn on the descriptor, it requires two separate operations.


I propose that the descriptor (or radix for numeric constants) be automatically shown when displaying any mode other than the default.


String formatting.PNG

Not only would this add to the readability of these constants but would eliminate the extra step to have to discretely show this valuable piece of self documentation.

If the developer did not want the descriptor shown, they they could manually turn it off.

Format Variant Probe

Status: New
by Active Participant crelf on ‎01-31-2011 08:21 AM

I'd like to see this rolled into LabVIEW core:

Enable logging in Application Web Server

Status: New
by Member Biggeveen on ‎01-31-2011 03:02 AM

My idea is to enable access logging for the Application Web Server.


In this way access to a web service can be analyzed which is also useful in debugging timing or performance problems of your application. To facilitate easy analysis, industry standards like the "common log format" or "combined log format" (link) should be used, then analyzer tools like AWStats can be used. The Appweb Embedded Web Server, which is the core of the Application web server, does already support logging so getting this running should be easy.

Graphical SET/GET BIT ...

Status: New
by Active Participant manu.NET on ‎01-31-2011 02:13 AM



It should be nice to have graphical tools toGET or SET a bit in an integer. (I8 , U8, I16, U16 ... ) 


Today it is possible to Set / Get bits with "Bitwise operators and, or ..." integer to boolean array, boolean array to integer ...

But i think this is a "C like programming way":smileysad:, not a LabVIEW graphical way.:smileywink:


It should be interresting to GET the value of a bit using something like ...

  • A special unbundle
  • A tools like an index array

It should be interresting to SET the value of a bit using something like ...

  • A special bundle
  • A tools like a replace array subset

It should also be interresting to get / set a bit of an integer in a "Inplace structure"


I think this idea could clarify the way to access Bits in Labview ... and clarify the readability of a block diagrams.:smileysurprised:

In place of using integer masks, integer to boolean array, and , or, XOR ... the set bit / get bit could be more userfriendly.


I think that this idea could also be usefull in LabVIEW FPGA.



MathScript should handle more than 2 indices

Status: New
by Member ket on ‎01-30-2011 11:27 PM

As of now Labview Mathscript can handle only 2 indices. for example:

Mathscript can execute the following

for i = 1:10

    for j = 1:10

        B(i,j) = i+j



but it can't do the following:

for i = 1:10

    for j = 1:10

        for k = 1:10

            B(i,j,k) = i+j+k





I propose that Matscript should handle more than 2 indices.

The output then would be a 'n' dimensional array, where 'n' is the number of dummy indices.

When converting a new VI back to LabVIEW 8.0, we get tons of warnings in the form:


The object "Multiply" does not support output configuration in the previous version.
The object "Multiply" does not support output configuration in the previous version.
The object "Subtract" does not support output configuration in the previous version.
The object "Add" does not support output configuration in the previous version.
The object "Multiply" does not support output configuration in the previous version.
The object "Divide" does not support output configuration in the previous version.
The object "Subtract" does not support output configuration in the previous version.
The object "Divide" does not support output configuration in the previous version.
The object "Divide" does not support output configuration in the previous version.



(see also this recent discussion, especially my comment).


The idea is that these warnings should only occur for function instances where the output was actually configured to be different from the default.


The current problem is similar to the problem with the boy who cried wolf, finding important warnings in a huge pile of useless warnings is like finding a non-magnetic, non-metallic, non-fluorescent needle in a haystack, and it is easily possible to miss something that is actually important.

Multiple Control Property Editor

Status: New
by Trusted Enthusiast on ‎01-29-2011 10:01 AM

It would be useful if a tool were distributed with LabVIEW that would show all controls for a selected vi in a table along with their properties. The properties can be edited in the table.


I already have built a tool that lets me open a vi and view and edit the Tip-Strip, Caption and Description properties. But it is lacking. It would be nice if it could view/set other properties such as default values, fonts, colors, numeric representation, etc.


Of course this would require somehow grouping controls by class since for example strings do not have a numeric representation.


Other features could be the ability to filter or search the properties, and to highlight the control on the front panel when the property row is double clicked.


Attached is a screenshot of the simple tool I built to give you an idea what it looks like.





0 Kudos

Waveform Graphs Axis drop down menu

Status: New
by Member OwlMan on ‎01-28-2011 04:03 PM

I have an application where it would be nice to change the data displayed by clicking on the y-axis or x-axis labels themselves as oppose to a separate enum type, button or switch residing outside the graph.


For example:


If I want to look at Voltage or Current vs frequency or time currently you could use enum types outside the graph. It would be handy to  select the y-axis label in real-time (during or prior to runtime) and change the data displayed. If you click on the y-axis label you can have enum type drop-down that is read horizontally and when you select the unit you want the label would be displayed vertically or make it custom depending on what the user prefers.


The same thing can be done for the x-axis. So in one graph I can click and select the x-axis label and select Time and selelct Current for the y-axis and depending how I set my program see the data displayed as it should be in real time in one clean graph. No side buttons or switches.


Would anyone else like to see this feature? Thanks.

Free labels and Name labels can be set to have transparent backgrounds on the Block Diagram.  For consistency of BD labels I have to manually go and set the wire labels background to be transparent to match.  If I don't my wire labels complain that they are treated as "second class labels.":smileysad:   Stop the discrimination! and give me the option to "Use transparent wire labels":smileywink:

wire labels.PNG

I have seen a few posts online indicating a couple of changes here and there for LVMerge and LVDiff.  I think the main problem is that we just want it to work with third party SCM tools like Mercurial / TortoiseHG, SVN / TortoiseSVN, RTC (Rational Team Concert), Surround, ect.  The ability to check in and out from project explorer is not quite cutting it.  With more and more developers using distributed SCC products like GIT or Mercurial the ability to merge and diff becomes really important.  Here is a list of what I would like to see in newer versions of LabVIEW and the LVMerge and LVDiff tools that would give us more time to develop code and less time spent managing software.


1. Both LVMerge and LVDiff work ok with a single vi, but not that well when hierarchies are different.  Most SCC applications will only download one file or the files that are different between change sets when merging or differencing change sets.  The basic problem is that in order to diff or merge LabVIEW requires the vi to be loaded which requires loading dependencies.  If the merge and diff tools didn’t require the vi’s dependencies to be loaded into memory then many of the issues just go away.


 I understand the technical challenges in order to implement this feature, but I think it would be a far better approach then trying to write a huge amount of code in order to handle multiple SCC tools.  Even if that code was written the workaround solutions are not pretty.  For example you would have to download both change set’s entire hierarchies to disk and then compare them.  How well will that work with very large projects?  Or with a merge where you need three version of the hierarchy?


I think the better solution is to just make LabVIEW files act like text files when diff and merges are performed.  The information in the LabVIEW file points to dependencies, and if those dependencies’s attributes change then flag them, but LabVIEW should be able to generate the LabVIEW "file" in a vacuum for differencing and merging.  May require caching more information about dependencies then what is currently saved in the vi, but I think that would allow a better merge / diff utility.


2. Support differencing and merging of all LabVIEW file types (projects, xctls, classes, libraries...).  Sometimes the text merge features in some programs don't take into account the complexity of the relationships between LabVIEW files.  It would be nicer to have a visual diff in terms of how LabVIEW treats the file (e.g. how TestStand differences sequence files).


3.  This is more of a bug fix, but improve the merge windows.  I have found a couple of situations where the code being merged is not even shown in the three windows (base, theirs, mine) and I cannot scroll to that location in the code to intelligently perform the merge.


4. LVMerge exe exits right away before the merge is complete.  TortoiseHG thinks the merge is complete for a file when the exe exits so it blows right past all of the other file merges so only the first file is merged.


5. Cover these use cases as differences between change sets when merging and differencing (item 1 solution should cover these):

Setup: use TortoiseHG to difference an entire change set in the repository with the local drive, or merge two change set in the repository.

  • Moved files (not just vi's) in the hierarchy
  • Deleted files in the hierarchy
  • Files added or removed from classes/libraries/projects
  • File 1 changed and dependency File 2 changes it's connector pane connection to work with the changes in file 1
  • Both new change sets add the same file that the base change set does not contain
  • Same as the last item, but added file has a different location on the hard drive between the change sets

There are probably more that I am not thinking of, but that would be a good start.


6. Simplify the entire process by providing a real IDE for merging and differencing files.  I am envisioning something with a hierarchy of views like Beyond Compare.  It would allow you to simplify some actions at a high level, but would give you the power to perform advanced actions.  For example, present a list of differences, types of differences, and the types of merges possible. 

  • Maybe some files can be auto-merged
  • SCC thinks the files were different but there are only cosmetic changes
  • User could choose between a deleted file or a changed file
  • Two versions are different but the user knows which one to choose without performing a merge.

The user should be able to have a quick view (no loading dependencies), or double click on the item and a new tab comes up that allows an actual file merge (vi, class, project, ect.).


 I think a tool like that that has the ability to interface with third party SCC tools would be a huge timesaver especially when dealing with distributed environments where merges occur more often.  It may need to stream all of the changes from a tool like TortoiseHG before performing a merge (probably easiest implementation), or rewrite the GUI for managing Mercurial or GIT change sets directly.


 The other option is to say "just use a check in check out central repository SCC", and I would say Phooeey! to that. :smileyhappy:  After using Mercurial with TortoiseHG for a while I would not switch to anything other then another distributed SCC application...even with the difficulties with the merges and differences, using another system still poses similar problems (sometimes even worse) and the software management in those programs just stifles productivity.  Has anyone ever tried to move a class and its members to a different directory after the code has already been checked into an SCC tool like Perforce?  How about managing a multi-branch project where stable release updates are not only applied to the trunk but to a major feature branch?  Painful...


I think that these changes to the LabVIEW development environment will move us from “writing LabVIEW code” to “software development using LabVIEW”.

Allow Deploy Libraries Invoke node to work with project based bound libraries

Status: New
by Active Participant viScience ‎01-27-2011 10:56 PM - edited ‎01-27-2011 11:01 PM

Currently, the Deploy Library Invoke Node and DSC Deploy Libraries vi will only work with bound libraries that have a PSP based URL. (\\\process\variable)  But there are some use cases where you need to have logical URL's (\\cRIO1\process\variable) that will adapt to changes in the .alias file which maps target names to IP addresses.  If this is your use case then it is tedious to do the same thing programmatically since you will have to create your bound libraries with an initial default PSP URL and then programatically modify all URL's based on a 'designated' target IP.  Since the project can do this I assume that it should be relatively easy to provide this functionality.

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
Idea Statuses