Home > Community > 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

When searching for text in LV 2014 (from 2015 DS1), it appears that the Window Title text isn't picked up by the search. 


To verify this, I created a new VI, and modified only the Window Title (File -> VI Properties -> Window Appearance -> Window Title, Click OK, Save VI).  Then press Ctrl + F, Select Text, type in a word in the Window Title.  Not found .


We should be able to search on any text saved anywhere in the VI (in cluding VI properties like Window Title).  Please expand the find capability to search Window Title and any other relevant fields.

FPGA code allows I/O references to be used so that code can be re-used/abstracted, like this


This could/should be extended to cRIO C-modules so that code can be re-used on multiple modules. This would require the 'cRIO Device' property node to return an array of I/O Refnums that could then be passed to subVIs or other modular code.


For example, if I have code for an analogue input module (say, NI 9205) which filters and processes the data, and I wish to re-use that code in multiple experiments I have to manually change the module name in each IO constant or node (Mod1/AI0 to Mod3/AI0) if the module moves or I need more than one of the same type.


Conversely, if the cRIO Device property could provide the I/O references, the code could accept a cRIO Device constant and the reusable code extract the I/O references. The code would then adapt from Mod1/AI0 to Mod3/AI0 as the cRIO device was changed from Mod1 to Mod3.


It would be added to these properties.






User Colors. 18 is not enough!

Status: New
by Proven Zealot Proven Zealot on ‎02-08-2016 03:04 PM


User Colors 1-16 are now pre-defined by the default LabVIEW.ini file  that leaves us developers with only two.  Why 18 total?  This needs some adjustments IMHO!  It should be easy to implement but, can't be done without hacking the ini editor

"Build Path" should be growable

Status: New
by Trusted Enthusiast Trusted Enthusiast on ‎01-30-2016 05:36 AM


                                            "Build Path" should be Growable


                              something like this,




Labview installer resizable

Status: New
by Member PalleM on ‎02-04-2016 08:49 AM

I just finished installing LV15 (and device drivers) on a new PC and I think the installer window could use an upgrade.

When expanding the different features you can install beyond 2-3 levels, they disappear out of the narrow tree-area. 


It would be awesome if I could then just resize the entire installer and it would grow the tree (and description) so I didn't have to use the little horizontal scrollbar


installer with 3 levels expandedinstaller scrolled to the right

Tensorflow API for LabVIEW

Status: New
by Knight of NI Knight of NI ‎02-04-2016 02:28 PM - edited ‎02-04-2016 02:28 PM

TensorFlow is an open source machine learning tool originally developed by Google research teams.


Quoting from their API page:


TensorFlow has APIs available in several languages both for constructing and executing a TensorFlow graph. The Python API is at present the most complete and the easiest to use, but the C++ API may offer some performance advantages in graph execution, and supports deployment to small devices such as Android.

Over time, we hope that the TensorFlow community will develop front ends for languages like Go, Java, JavaScript, Lua R, and perhaps others.


Idea Summary: I would love to see LabVIEW among the "perhaps others". Smiley Very Happy


(Disclaimer: I know very little in that particular field of research)


Orientation of Tab Text

Status: New
by Active Participant paul_cardinale on ‎02-02-2016 11:02 AM

When tabs are on the side, the text should be correctly oriented:


LV exe run as admin mode

Status: New
by Active Participant spsimona on ‎01-28-2016 02:28 AM

What if you need to run exe as admin mode?


Currently Build Specifications is not enought for doing it.

Here you are what you need to do:


1. Built the executable

2. Install mt.exe (https://www.microsoft.com/en-us/download/confirmation.aspx?id=8279)
3. Opened cmd as adminstrator and ran mt.exe -inputresource:"Application directory\application.exe" -out:application.manifest
4. Opened application.manifest and changed input="asInvoker" to "requireAdministrator".
5. Saved application.manifest
6. ran mt.exe -manifest:application.manifest -outputresource:"Application directory\application.exe";#1


Is it an effective method?


It would be better the following:

1. Create Manifest

2. Easy modification in My Application Properties




Hope it helps to do a more effective LabVIEW!



There has been always the need of opening the file/folder location in windows explorer, but I guess every application uses the trick of doing it through "System Exec.vi" or "Open URL" or Win32 API.  There is no LabVIEW native function to directly open folder/files in windows explorer directly.


Below threads discusses various methods to achieve this...







It would be nice if LabVIEW comes with some native function like below


File Folder Idea Exchange.png

I think its will be very usefull if IMAQ draw.vi has also line with and fill parameter.



Include A Python Script Node

Status: Duplicate
by Member JamesTomkins on ‎02-07-2016 03:19 PM

Include a python script node that you can create and run python code, functioning exactly as the c script node does but using the python language, there is a growing support for python in the scientific community (I know of a good few university lecturers and professors who use python), and it is a great programming language for beginner programmers such as university students.


This could be included as a feature in labview itself or be a labview addon.

Currently enums can not be in a cluster that you want convert to JSON. It would be great, if this could be added.


Either the enum value could be converted to its internal representation (e.g. u16) or the value could be saved as a string (make it easier to read the JSON and parse it outside LabVIEW).


The unflatten should be able to handle the u16 easily to convert back to enum or take the string and search through the enum of the datatype that one has to connect to the vi. If there is no match the VI can issue an error.


Increment File Suffix Without Creating a File

Status: New
by Trusted Enthusiast Trusted Enthusiast on ‎02-03-2016 04:50 PM

Starting in LabVIEW 2015 we got a neat new function that can create a unique file path, and allows to not overwrite a file that might exist with a similar name.


Increment file.png  



This is such a cool function and I could think of a ton of places where I needed to save some temporary data and just wanted a unique name expecteing files to be cleaned up later.  Or give the user a checkbox which wouldn't overwrite the existing data, and then not need to worry about generating my own unique name.


Alas this function fell short of my expectations.  Why?  Because it creates the stupid file, and returns a reference to it, instead of just generating a path that I can use.  What if I want to use this with the report generation toolkit and generate a unique file name?  Well you can but you need to close the file reference it made, and possibly delete the file.  Same with if you want to use this on a TDMS file, or a Configuration INI file, or a zip, etc.


I suggest either adding another function (polymorphic?), or making an optional input to this function, which does everything it currently does except don't run the Open/Create/Replace function there by making the file, and returning a file reference.  Every time I've used this function to date it has been followed up with a Close File, then a Delete function.

Extend Array Functions to Mirror OpenG

Status: New
by Trusted Enthusiast Trusted Enthusiast on ‎01-07-2016 02:12 PM

I've already made a post on extending File I/O operations so I figured why not make a post on my most commonly used OpenG palette, the array palette.


There are so many good nuggets of Array manipulation code in OpenG.  This stuff isn't perfect, and could be optimized, but the convenience of it makes sense especially when you realize there is so many things you can do with arrays.  Lets start with the Index Array, one of the most commonly used functions.




Here we see the native function allows for an N dimensional array to be indexed.  The OpenG function only supports 1D and 2D arrays.  And when using a 2D array, the OpenG function must specify both a row and a column, you can't index an entire column or row.  Both of those are very useful features of the native index, but there is something the OpenG function does, that the native doesn't, and that is index multiple indices.  You can pass in an array of indices and pull them all out in the order defined.  This can be used as a reorder function that takes an array and scrambles it the way you like.  Adding this feature is already on the idea exchange.




Again when it comes to polymorphism the native function beats OpenG.  The native delete supports deleting from N dimensions where OpenG is just 1D or 2D.  But OpenG allows for deleting multiple indices from an array, and if it is a 2D array you can specify if you want to delete rows or columns.  This would be a nice addition to the native function.


cond index.png


A conditional auto index function doesn't exist natively in LabVIEW.  You can perform a similar function with the conditional auto index tunnel on a for loop but having a single function would be useful.  This idea is on the exchange in multiple places, Link 1, Link 2.


Remove filter.png

Ever need to remove duplicates from an array?  Or remove all zeros or NaNs from an array?  These two functions do just that and on the forums all the time are requests for functions like this with no direct replacement on the native palette.  A nice feature of the remove and filter are they output the indices that were removed.  Combined with the fact that the delete, and index accept multiple indices make these very useful.  Also the items to filter for the filter can be a scalar or array which is nice.



Ever want to sort an array and know how it was sorted?  This OpenG function can do that along with specifying what order, ascending or descending to use.  The OpenG sort also supports 2D arrays where you can specify if you want to sort on rows, or on columns.

More array operations should support timestamps (threshold, interpolate, etc)

Status: New
by Knight of NI Knight of NI ‎01-02-2016 03:52 PM - edited ‎01-02-2016 03:54 PM

(This is different and less controversional than  this related old idea)


Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.


As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.


If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).


Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.




IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.




The documentation states that the Tip Strip is limited to 255 characters, however the Documentation tab of a control Properties page does no checking against that limit. One will only find out if there are more than 255 characters during execution, when the tip strip is truncated!


Please enforce the character limit of the Tip Strip input box, at design time. Also, while at it, make that box taller.





Status: In Beta

The minimum size of classic framless colorboxes should be two, not five

Status: New
by Knight of NI Knight of NI ‎01-10-2016 04:49 PM - edited ‎01-10-2016 06:36 PM

I sometimes use arrays of classic frameless colorboxes to quickly display a color table.


Unfortunately, the minimum size of these elements is 5 pixels Smiley Sad, making a 256 element color ramp 1280+pixels wide, showing redundant information in 5 adacent pixel columns each.  If we display the color ramp vertically, it would not even fully fit on a common 1080p display!


This makes it too wide to correctly display them in the forum and forces a size reduction that makes all other text and diagram code illegible.

(Yes, we can right-click...open image in new tab, and click the image to display it 1:1 (in chrome), but that's more work and not everybody knows that)


It would be perfectly OK if we could make these elements only 2 pixels wide (or high), making the array display a much more reasonable 512 pixels and keeping the front panel to a more reasonable size.



Idea summary:

The minimum size of the classic colorbox (frameless) should be 2x2 pixels (or even 1x1?) Currently it is 5x5, i.e. too big.



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.

If You drag a tunnel of a loop, case structure or any other structure along the border over a corner, then

the connected wire becomes hidden behind the frame.


Sometimes, the wire looks alike it is connected to another wire instead - like in the example below.

I fell into that trap, because I've just seen the frame to the right and didn't expect, that the wire was

connected to the tunnel near the bottom.


Wouldn't it be great to break up the wire with a 90° corner and place it in the visible area?




More similar situations like this are posted in this thread:


Add proxy support to the http library for secure https transactions

Status: New
by Active Participant aartjan ‎02-04-2016 12:37 PM - edited ‎02-04-2016 12:45 PM

I created an application that talks to a SOAP webservice. Unfortunately the NI HTTP does not support https behind a proxy (using the connect method). See this thread. It is unfortunate, since the curl library underneath is much more powerful. I have to overhaul my code to implement another solution.

Encrypting http transactions with configSSL.vi is cumbersome as well. The documentation on this VI could be much better. 


HTTP Client.png

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!
Idea Statuses
Top Kudoed Authors