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

Structures with enabled Auto Grow

Status: New
by Trusted Enthusiast on ‎06-23-2009 08:06 AM

I don't like and don't use the Auto Grow option of structures. Therefore, I always uncheck Place structures with Auto Grow enabled in the LabVIEW options. A visual mark on the structures or a specific entry in the Find and Replace dialog box would help me to locate these structures on inherited VIs.


Auto Grow structure.jpg

Auto Grow.jpg

While NI provides (thank you) reasonable support for OS X these days, the support for installs and updates "on line" are very far behind those for Windows.


For instance, there does not appear to be any option to download Labview 2010 for Mac but I can for Windows.





When you use the "View cluster as icon", the icon which replace the cluster is created automatically depending on the types included.

But when you create a control/type def, stric type def, you have the ability to define your own icon.


So it should be nice to replace the "automatically created icon" by the user defined one.


This icon could be, a little bit, visualy modified in order to differentiate VI's icon and cluster icons. (Something like an additionnal border ???) 





It would be nice to add a new menu item in Labview IDE, which could close all executing VI's.


This could solve the problem of "running Modal VI's" which can "block" an execution.


This could also be helpfull to "clear" the execution context when you have bad closed "detached and assynchonous executing VI's".


The top, would be to get a report (a list of VI's in a window) of the forced closed VI's ... It would be helpfull for analysis.



New Array Collector Primitive

Status: New
by Member smmarlow on ‎06-01-2011 10:44 AM

Getting the best performance while accumulating array values for display can take up a bit of space.  I propose a new primitive, either an array primitive or a node structure (like the feedback node) that accumulates an array of a specific size.  It should be smart and size itself automatically if dropped into a loop, the way indexing output tunnels do.  It should also keep track of how many times it has been called and return only the points collected, or the last N points if the size input is wired.  It is functionally equivalent to the "Collector" express VI, but has the ability to automatically size itself, accept a wired size input, and is truly polymorphic.  It would also put the best of memory management to work by NI's clever engineers to maximize performance. Here is my best shot at its implementation as an array primitive:




With reference the post in the below link


The idea of decreasing the size of the "close reference" works fine if you wired from a propert or Invoke Node, It won't fit for the references coming out from VIs.


So my idea is to slightly increase the size of "Propery Node" and "Invoke Node" so that it can fit with VIs as well as "Close Reference". 

Sample screen is attached Below


Property Node.jpg


If you like this Idea don't forget to give kudos,


Best Regards



When you "Apply Icon to VIs" in a LabVIEW Library and the VIs are check into source control, then LabVIEW will display a dialog that each of the VIs that are not checked out of source control already exists and you do not have the permission to replace it when you attempt to save all the VIs in the library. LabVIEW can make this operation more user friendly if it checks out the VIs from source control before applying the icon to the VIs.



Use the attached zip file to reproduce the behavior. Here are the steps.

  1. Detach and unzip the attached
  2. Check in all of the files into source control.
  3. Open Project.lvproj in LabVIEW.
  4. Configure Source Control so that the Project and all of the files in it are bound to source control. Confirm that all the files in the project are NOT checked out.
  5. Right click on Project.lvproj>>My Computer>>Library.lvlib and select Properties.
  6. In the General Setting page, click on the "Apply Icon to VIs".
  7. Click OK to dismiss the dialog.
  8. Right click on Project.lvproj and select Save All (this project) or click on the Save All button on the toolbar.

If the current behavior exists, LabVIEW will display a dialog that states "Cannot save VI "". The VI already exists and you do not have the permission to replace it." It would be more user friendly if LabVIEW offered to check out the vi from source control before it applied the icon to the VIs in the library.

Radix in Case structure

Status: Duplicate
by Member OlegBr on ‎12-23-2011 01:51 AM

Add Radix in select field on Case Structure for numerical and string.

Now impossible to insert in select field symbols as "\t, \n, \r", etc.


String Control should support TAB

Status: New
by Member Peter_FitzGerald on ‎08-03-2012 03:26 AM

The LabVIEW STRING control should support the TAB character


   String should have a property called TAB.Enabled (boolean, default=False)

   String should have a property called TAB.Width (numeric)

   String should have a property called TAB.Width.Unit (enum: Char, % of Text.Bounds.Width)


thus the TAB feature could work nicely with proportional as well as fixed width fonts



Array size via Property node

Status: New
by Trusted Enthusiast ‎06-12-2009 12:33 PM - edited ‎06-12-2009 12:33 PM

When developing a  utility to traverse any control using VI Server and save its contents to a file (similar to the OpenG utility using Variant) it is quite challenging to find out the size of the array's data.


There are various workarounds, but all of these are relatively tedious and over-complicated.


Why don't we have a "array data size" read only value on the property node of an array?


This would make things MUCH easier.



Message Edited by Intaris on 06-12-2009 12:33 PM

I have run into the problem from time to time that I create a new build specification in my project, hit the Build button in the setup dialog just to have the build hang or crash LabVIEW. To add insult to injury when I opened the project file again (sometimes even after recovery) that new build specification was not there since the project was not saved before building.

I have now trained myself to resist the temptation of hitting that Build button. Instead I will exit the dialog, save the project and then start the build via a right click.


I would really like to see the project file being saved before the build is executed. 

diagram disable to allow for include or exclude more easily

Status: New
by Trusted Enthusiast ‎05-26-2011 04:43 PM - edited ‎05-26-2011 04:46 PM

The diagram disable structure is great for commenting out code, especially during testing when maybe all parts are not functioning. However, I wish as I expanded and contracted it AFTER IT HAS BEEN PLACED ONCE that it would enclose the code already in place. Because it doesn't, I end up removing and redrawing the structure to include and exclude what I want as things change. Please see picture below for what I am proposing.


provide a means to see dotnet or externall dll documentation in Labview

        /// <summary>
        /// the file location where the data is to be logged.
        /// </summary>
        private string _path;
        /// <summary>
        /// the file location where the data is to be logged.
        /// </summary>
        public string Path
            set { _path = value; }
ie to be able to see the following
the file location where the data is to be logged.
when the property node is touched In labview 




This idea would only be useful in situations where the event data node is unused.  There are times when we have an event but do not use the event data node.  In these situations, the node takes up space. 


The proposed idea is to make the event data node hideable.  The little dark rectangle can still be left there so that clicking or dragging on it makes the node visible.


Idea Exchange.png

Mark VI as toplevel

Status: New
by Knight of NI on ‎06-05-2009 11:24 AM

LLBs always had the capability of marking a VI as toplevel.


I wonder if it would be possible to set a flag inside a VI so a VI is recognized as such from within e.g. windows explorer. (e.g. different default icon). Since this requires OS integrations, I don't know if this is even feasible.


Still, It should at least integrate with the LabVIEW project.


The default settings could be very simple:

  • A VI without any defined connectors in the connector pane is "toplevel".
  • If there is at least one defined connector, the toplevel designation is lost.
  • There should be a way to overwrite this in VI properties.


Many times, people attach a zip full of VIs without telling us the name of the toplevel VI, so this idea would limit the number of candidates to inspect.

Upgrade LV Project RT targets

Status: New
by Active Participant Thoric on ‎07-30-2012 04:14 AM

I've had a look around and can't see anything in here like this already (which surprises me so I'm suspicious that it's just the search algorithm failing) but I'd like to see options in the LabVIEW Project tree for changing target hardware.


For example, I have a development underway using a cRIO-9114 chassis with a 9024 controller, and a 9144 EtherCAT expansion chassis. The primary chassis is about to be upgraded to a 9116, as we need a bigger FPGA, and although the hardware upgrade process is straightforward, upgrading the chassis in the LabVIEW Project is not a possibility. Instread, I need to create a whole new target, and copy and paste every VI, node, FIFO, DMA etc. across. There's quite the possibility that I'll miss something, or the new target won't have all the same settings (Scan Mode period and priority settings for example), leaving me with that niggling feeling that something under the hood will be wrong. It would be much neater if this was an automated migration.


Furthermore, as the hardware is not here yet, I need to create the new target and all it's modules manually, which will take me quite some time. An automated migration would save me that trouble.

A while back, Dany Allard suggested merge and diff tools for projects and libraries.  I have a request that is similar, but more specific:


When opening a project, if for various reasons LabVIEW is unable to locate dependencies of a build specification, it would be truly helpful if the user was prompted to locate said dependencies.  As it stands, by my observation LabVIEW silently omits missing build spec dependencies - this can be frustrating and dangerous.


Here's some context: I have lots of projects with 5+ build specifications. When I move directories, files, or even change LabVIEW versions, my build specifications stealthily fall apart, sometimes very subtly.  Often I don't realize that my build spec is broken until I attempt to build, only to realize that it's a hollow placeholder in my project file.  The most insidious case is when the application builds successfully, but is missing dynamic VIs, etc.  This omission might go completely unnoticed without rigorous testing.  LabVIEW should, in my opinion, give the user some indication that the build specification is missing dependencies or is "broken."


One hypothetical way to indicate this status might be to list the build spec in red font within Project Explorer, and have dependencies listed in dimmed font within respective build spec dialogs.  There ought to be a "resolve conflicts" button in the build spec dialog;  Perhaps this functionality could be integrated in the main conflict resolution dialog somehow.


Furthermore, there ought to be an option to import build specs from other projects.  (Okay, maybe this should be a separate request)  When importing, the aforementioned conflict resolution process should be leveraged to make the import proceed smoothly.


Has this already been requested?  Thanks for listening.



Check Glyph .PNG's on Load

Status: Declined
by Member evan1138 on ‎07-27-2012 12:12 PM

Corrupt glyph .png's can and do cause all glyphs in icon editor to become invisible, or maybe produce other symptoms. The user then looks in many places and eventually fixes the problem by some kind of reinitialization or synching, but the underlying issue is not understood.


In a mature feature like glyphs I would expect a check-on-load action that would report corrupt files and save (some) users lots of effort.

Status: Declined
Reported as CAR 365008.

"Variable" constant and Strict Type Def behaviour

Status: New
by Active Participant Jorge_C on ‎07-26-2012 04:51 AM

Hi all!


I know the title doesn't make sense, so I will try to explain.


I think it would be a good idea to have a way to define values similar to the C instruction #define. In C code, you can define constants and change its values all over the code during development time.


Right now, there is nothing like this in LabVIEW. You can use controls and variables, or controls and property nodes.


(Strict) Type Defs for controls have kind of the same philosophy, you change things on a single file, while all the instances are updated (but there is no way to define a single value for all the instances of a control). I guess in LV it would make sense if we could define a constant file, and place it in every block diagram that we want to get that value.


Don't you think it would be a good idea?


I tried to define a Strict Type Def with a range where only one value is possible, and the coercing options. Anyway, the behaviour is not what I expected, as it seems that the control doesn't look at its own properties until you try to change its value. If the control has a default value of 4, and you change the valid range to [5,5], the control will have the 4 value until you try to change it (and then the value will be coerced to 5).


I don't think that is a good behaviour, do you agree?


PS: I think it would be great to have a "User Defined Type Def", in which you could define the things that stay the same and the thing that doesn't, but I know that idea is not mine Smiley Very Happy.



This is an offshoot from this thread in the forum:


The Shared Variable Refnum and Shared Variable Control (for the DSC Module) is essentially the same concept and I think that merging the two should be considered.  The recommendation from Daniel REDS in the NI Forum thread was that I post an idea to make a silver control of the Shared Variable Refnum.  I would say that would be nice, but I think that the two controls being merged into one would be more ideal since they both contain essentially the same Variable browser and conceptually are referring to the same thing.



shared variable 0.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