LabVIEW Idea Exchange

Community Browser
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!
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Currently, "build path" function has input "base path" set as recommended. This can cause issue when you accidentally do not wire this input. By default there is empty path, which is not really helpful and even if there was any case when you want to wire empty path to build path function, you can easily create constant. Therefore, it would be much more user friendly to have "base path" input of "build path" function set as required by default.

can we have an option of loading only user-specified rows from a delimited spreadsheet instead of all rows, perhaps allowing the user to specify which and how many rows to read? this is potentially useful if the user want to read the select or latest few rows (typically at the last few rows due to write append) without having to load unnecessarily large amount of data into memory.


implementation wise, can use a row index and length input optional terminals defaulted at index:0 and length:-1, to yield all rows by default for the rows (note: terminal name changed) output terminal. index:-1 to specify from end of file and non-zero length:L for how many rows from the end of file (-L for reversed order, last row on top). if index:-1, the data read will be replacing elements within a fixed sized array of L elements until the EOF returns true. for example, index:-1 and lenght:5 would yield last 5 rows from file. 


read delimited spreadsheet.png

thanks for reading and have a great day

There are already several Ideas on the exchange regarding custom error-code files. A subset are listed below:

Project error code files (request to locate error file near lvproj file, or via Project properties)

Error txt file (allow specifying a path when calling General/Simple Error Handler, store the custom file somewhere not in <National Instruments>/{Shared,<lv-version>}/...)

Make custom error code files part of a project (allow project-level error codes, not stored in user.lib)

Error ring without file (request for an error-ring typedef that could be stored in the project's source code collection)


My suggestion here is most like the last - I'd like to suggest a file type like a .ctl (or perhaps via typedef, if technically better/more implementable) that can be added to a project, library or class and contains a list of errors.


Ideally, these errors should be only possible to throw from inside the library, but must of course be visible from outside of the library.

Implementing these at the project level restricts the possibility of use with PPLs, reusable libraries, etc, because the project file is a dev-only construct (as far as I understand), unlike classes and libraries (which are part of what you distribute in whatever form you choose).


The ability to store these files in a library or class also allows the possibility of scoping the error code, such that the handler can more easily identify the source of the error.


LabVIEW already categorizes it's errors into broad sections (LabVIEW, MAX, NI Platform Services) etc and so perhaps these could be used as the scope of the existing, built-in error codes, although I'm not sure if this would require significant work or not... I suspect many things seem easier when you're not the person who will implement the changes!

So this isn't a huge deal, but it would be nice if we could put an array of classes into To More Specific Class to convert all of them to the more specific class. There are handfuls of functions that work well on both arrays and single elements (the Math functions, Close Reference, etc).


Error Out would need to become an array as well. I can't think of anything at the moment that this might break, or any poor patterns it might enable, it would just save a For loop here and there. I made a quick example vim just to illustrate, but it'd be nice if it was part of LabVIEW core.



Traditionally LabVIEW has treated Strings and Unsigned Byte Arrays as being the same. This is nowadays a little unfortunate as all UI systems use some kind of encoding so Strings are not generally interchangeable with Byte Arrays anymore.

In trying to stay for binary data as much as possible with Byte Arrays instead of Strings, since that would be the sensible thing to do, the Unflatten from String (which should rather be called Unflatten from Stream) puts a totally unnecessary wrench into this.

I always had hoped that LabVIEW would change the default binary data stream format to a Byte Array at some point but this while it would be possible, is a fairly pervasive change that would require many backwards compatibility decisions that I unfortunately don't see NI going to spend time on anymore. This change however would be a very small change that has zero backwards compatibility concerns and almost no work to add to the existing LabVIEW software.

This same change has been for instance made to the TCP Write node some versions back already and could be also applied to the VISA Write! Smiley LOL

When searching for text in a vi or group of vi's, the search isn't able to look inside an FPGA IO node/property /method and "find" a match if the text searched for is in the name of the item.


So if I have an FPGA DIO line configured as "MyBasicIO" and search for that text, it will not currently find any IO nodes for that item.


This is frustrating and time wasting if I want to find every instance of my setting a particular IO point.


So generally what I do is a search for an object of that type (for example, IO Node).  Then it finds all IO Nodes, not just the IO Nodes for the item I'm interested in.  So I have to manually scroll through the list to see which ones are for the point I'm interested in and which are for other points.

I would like to see an option or VI that save / load the state of a VI and there SubVI's at a certain time (all controls I guess).



In the development of measurement software it is important, in terms of reproducibility of measurement results, to implement an option that save all scalable objects at a certain time (device settings also program settings) which depending a measurement.


Save program settings:

I know there is a way to do this by calling the VI reference and get the control values with property node and save them. But I don't think that's an accurate way because you have to manually do this with every SubVI's reference if you won’t to save them too.

Btw: in LabVIEW NXG, which I really like, it seems no way to do this because there is no 'Get Control' property node?!



- two VI's which save/load all scalable program settings to/from file (hopefully in the standard data save VI Palette)

When using refnum arrays with auto-indexed tunnels in loops, I often bump into the absence of the submenus "Property for <ClassName> Class" and "Method for <ClassName> Class" in the "Create" Menu.

The submenus appear when right-clicking normal tunnels, shift registers, wires, subVI terminals, Constants, Controls, everywhere, except for auto-indexed tunnels.

image.pngThis idea is a revival of an old post from Darin.K :

which has been declined in 2015 for too low priority reason, but since it is still annoying now (e.g. with LV 2018), especially when using VI server (dynamic VI calls, UI elements manipulation, VI Scripting...), I think NI should reconsider it.



I love to align my controls on Front panel and I like to be base on my grid.

When you want to make your window multiple of your grid you have to be cery precise with your mouse and set to current panel size or do the calculation depending of the size of you grid.


Addind a simple indicator inside Window Size of the Properties window of the VI will help without a lot of effort.


Grid Multiple Idea.png


This can be added inside "Window Run-Time Position".


Best regards.

I really like using VIMs; however, I have been having a lot of issues when saving for previous versions / VIM based bugs.


What I would like is a right-click (under the advanced tag) to convert VIM to VI copy (which you could then save) and a 'tools>Advanced>replace all VIM instances in the project' tool.


I attempted to make this myself, but it turns out the 'Replace' scripting method doesn't work with VIMs and I don't really want to go down the route of deleting, placing, rewiring.


So either, could I suggest creating the tool, or providing the scripting functions for us to create the tool.


NB: This is the proof of concept I was trying out to change VIMs to VIs:

Order of operation:

  1. Get a reference to SubVIs and filter for VIMs
  2. Create a copy of the VIM and save as a VI
  3. Replace VIM with new VI

Converting VIM to VI.png


I would like to have the plot order decoupled from the legend list order.

Currently the first (data) plot is top on the diagram and top of the legend list.

Cool would be  two new properties per plot that define how the plot order and the legend order has to be sorted.

A bonus would be special values like <Always on top> (=0)  <Always on bottom> (+INF for watever datatype choosen I32?) , with a documention how conflicts are solved.


Starting in data provided order 

- if a number or <Always on top> is provided,  it will be placed at that index in the list and shifts all other down

- <Always on bottom> (the default value to keep the old behaveiour) just add to the bottom,


Or make all positions default 0 and start sorting from the last data entry .... or ... 


To reduce the inflation of properties one list for plot or legend order would be sufficient and the data order would define the other .

The Tree- Control and the Multicolumn Listbox support the presentation of a Symbols per row. But there are a lot of cases where there is needed more than one symbol per row. One very common scenario is the display of various states (Calculation completed: Checkmark; Results written to file: Checkmark; Assigned Application to open file: App-Icon...). NI does this already in the "Example Finder" window, so it is obvious there is a need for this feature.

I think it is a good practice to hold a pool of symbols, attached to the control, like NI does currently with the Trees and MCLBs. And for performance reasons there could still be the possibility to determine the columns to be capable to display symbols.

So from the LabVIEW programmers point of view there could be added the following properties / methods:

  • Symbol-Displayable Colums (property, read/write), (1D Array I32): Gets or Sets the indices of colums, which can show symbols and reserve space when the property "Visible Items->Symbols Visible" is set to true
  • Active Symbol- Column (property, read/write), (I32): Gets or Sets the Column-No which has focus for the next "Item Symbols"-property operation.
  • Set Column- Symbols (method, takes an I32 as Index for the Column, takes a 1D-Array of  I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by setting the Property "Item Symbols".
  • Get Column- Symbols (method, takes an I32 as Index for the Column, returns a 1D-Array of  I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by reading the Property "Item Symbols".

This should provide compatibility to the current handling of symbols since the property "Symbol-Displayable Colums" defaults to [0], so if "Item Symbols" is read or written to, it is meant to use the first column, which is status quo.

On all "Find Items" windows (Find Project Items, Find Items with No Callers, Find Missing Items), it would be nice if they were all sortable by file type.


And I think I saw this suggestion on the forums somewhere before, but it would also be nice if the windows didn't disappear everytime you clicked an item to go to it.

It would be useful to have something similar to C#'s LINQ in LabVIEW. Basically a way to "query" array of clusters/objects (and for some nodes even array of strings/numbers/whatever) without needing to use loops. I imagine nodes similar to invoke nodes, something like the below examples:

Query Nodes.png

If one wired an array of clusters one should be able to choose from the elements in the cluster, like an Unbundle By Name node. For the Where node one should subsequently be able to select how to filter based on the data type of the selected element. For example: Equals, Greater Than, Less Than, Greater or Equal to, In Range, etc. for numbers. Equals, Contains, Starts With, Ends With, etc. for strings.

Hi All,


i think it would be useful to have one VI which can check path constants whether they contains invalid characters or not. 

A lot of VIs doing some file operations returns errors if the file contains invalid characters but it should be checked before calling the VI with the file operations.


I found the `Is Name Multiplatform VI` which can check it, but it is hard to find that this VI will solve this question, accepts strings as input instead of paths, and also it has a lot of unnecessary in and outputs.

I think it would be would be more useful if there would be a simple VI with just one path input and one boolean output to check the path against the current platform.


What do you think about it?

Provide the possibility that auto generated inputs/outputs are named in english.

The language of the dev environment should not matter.

It should be possible to have a dev environment in whatever language, but still be able to consequently name all front panel/block diagram element in english.

Localizing auto generated elements where one wants to manually name all other elements in english leads to the unbearable situation where languages become mixed up.

It should be taken into account that english is the standard programming language language.


hello forum


given certain circumstances, the auto-incremental function for labels may lead to entirely different meanings. maybe sticking a non-printable character or a delimiter next to autonumber can solve this?


for instance, delimiter "- " in this case would make it even worse, but a non-printable character maybe... 

1st label: number: 0 to 1 

2nd label: number: 0 to 1 - 1

3rd label: number: 0 to 1 - 2

and so on

This idea has come up repeatedly over the years: a new VI created in a library* should default to private scope. The point of private scope is to limit the number of callers of a subroutine so you can freely refactor the subroutine and know, without question, that the only callers that you can be affecting are the ones inside the library. This allows you to make API breaking changes freely because you can know you are updating all the callers. Note that if we did this, it would almost certainly have a Tools>>Options setting to change it, but the idea is to make "new VIs start in private scope" be the shipping default.


Each of the other scopes is more permissive in some way, with public being all the way open. For APIs intended for reuse and long-term stability, use of those other scopes ought to be a conscious decision.


The vast majority of VIs within most libraries should be private. There are some weird exceptions**, but most libraries have a few routines intended for the world to call and a bunch of subVIs that support the public ones. But going and setting the access scope to private is a lot of work, and many developers never think about it. For small shops, this isn't usually a big deal, but the larger the dev team, the greater the danger of highly interlocked libraries caused by someone reaching for some deep subroutine that just seems so useful, instead of doing the right thing and refactoring that VI out into its own shared library. 


I've seen some of our customers get really badly bitten by this, but it is an issue that takes years to build up, and then requires expensive refactoring projects to fix (or cloned code, which is sometimes worse in the long run).


C++ and C# default everything to private unless you declare public; I think that's true in most text languages.


But LV is a programming language for non-programmers, and not everyone needs to understand access scope, so creating new VIs as private by default would push yet another concept into the "you must learn this" category instead of "learn this when you hit a scale where it is useful" category.


In the end, I think access scope is a simple enough concept, one that most people using libraries get familiar with pretty quickly, and switching something to public is easy enough to do. Therefore, I think switching the default would do more good than harm. So that's what I'm proposing here.


* includes plain .lvlib libraries, XControls, LabVIEW classes, state charts, and any other type of library NI may introduce.

** such as the NI Analysis library, which is hundreds of VIs packaged together, mainly for licensing reasons, less because they have shared functionality.

I find myself writing this type of code more and more recently.


ci current 2019-08-13_13-53-21.png


It would be nice to have an easier way of achieving this (for instance either of these below could work):


ci new v2 2019-08-13_13-53-33.png ci new 2019-08-13_13-53-33.png


Showing the false terminal could be done with the right click menu


ci new menu 2019-08-13_14-15-43.png





I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire.  I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal.  I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:


1.  Wire this specific VIM on error wires most often

2.  Likely don't want the VI to stall in the event of an error

3.  Would prefer to see that error propagated as quickly as possible like most other VIs do