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!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?

Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

I know this was asked three years ago, but TRDP was fairly new back in 2017 and is becoming more in use in the rail industry.


As we are going to be moving away from Multifunction Vehicle Bus (MVB) networks over to TRDP, we need a solution to continue lab testing our software using LabView to simulate a vehicle interacting with a control unit using TRDP.

It would be great if we could close the documentation editor window by entering <Shift> + Enter.  Several other LabVIEW IDE dialogs and text entry objects work this way already.  We can open the properties with a keyboard shortcut, and if we were last using the documentation, no mouse work is needed, except to close the dialog.  When I already have both hands on the keyboard, it would be nice to not have to grab the mouse just to close the dialog.




Edited to suggest using unused modifier key, Ctrl is already taken.

We often use property nodes to change controls appearance/behavior in a while loop but because of their added overhead, we don't want to do it every iteration, just when other values change. To get this effect you have to wrap the property node in a case structure and ti in the appropriate variables. this is bulky and hard to read at times especially because it encourages using "no names". Or you can create a sub VI with the right rappers on the inside but you have to pass in a reference. It would be great if there was a built in enable input on a property node (ideally without increasing the sizeof the top part). I even toyed with using the error in to get the desired effect (tying in a error or no error constant chosen by a case structure) but thought better of it (I think it gives the desired effect but sometimes you want to use the error input for timing control or actually as an error.

It seems like a simple request that would really clean up a lot of my code or improve performance if you are setting properties every cycle.

In many software packages, if you do a cut (ctrl+x) then paste (ctrl+v) it will move the item and then sometimes subsequent paste operations will make copies (sometimes they act like the clipboard is empty after a single paste)

In labview it is more like it makes a copy and deletes the original. This is somewhat unexpected behavior for me (maybe others find it normal). I would like to use it to move items around without having to drag somewhere in between (say if I want to move a terminal or local variable from one case to another I have to drag out while braking wire connection change cases and drag back in)  

For a control, if it had property nodes, connections in connection pane, events, or local variables all these connections brake or are deleted, and the new item is no longer connected to anything. If you do it on a property node, the new node is un-linked to anything. A local variable is the worst of all in my opinion. It deletes the original local variable but makes a new control that the new local variable is linked to. this seems like it would rarely if ever be desired behavior (you get the same problem just copy/paste on local variable as well). On the other hand just making a new local variable linked to the same control would be great for both cut/paste or copy/paste. 

LabVIEW do a lot of background changes on all VIs in the memory even if the user did not change anything.

You can recognize this when you close a VI and LabVIEW asks you for storing it or some of its SubVIs.

The can be prevented by enabling the options "Tread read-only VIs as locked" and "Do not save automatic changes".

Having an active read-only flag on several thousand VIs and removing / setting it manually is not really funny during daily development work. Wouldn't it be possible to prevent storing automatic changes independent from the read-only flag of the VI?

My use case: I have to open my Project sometimes in LV32 and sometimes LV64 to develop / run and compile the code. Each time LV wants to store all VIs when they have been stored with the other Bit-Version before. In each case I'm using LV2019SP1. The compiled code is already removed from all my VIs.




To my surprise there's no type specifier on the In Place Get/Replace Variant Attribute.


I post it as an idea even if I'm sure there's a good explanation about it. I would find it convenient if the Get Attribute type would match the one Set.


Is it because the new value could be of any other type? At least on the left side, if we could just specify the type as the regular Get Attribute it would be nice.







If I create a zip file for my build distribution in a LabVIEW project, I can choose "Zip entire project" for Source Files.  In this case, the lvproj file is included.  However, if I don't check that box and instead pick specific files to include, the lvproj file is not included.  


Sometimes, there may be installers and other drivers included in the project that I don't always want to include for size reasons during development. 


I'd like to be able to choose whether or not to include the lvproj file when making a zip.

I want to suggest Case Structure Selector comparison to dynamically changeable values.

Now Case Structure Selector compared to constant Boolean/eNum/Numeric/String values.

I suggest to compare the Selector input to External Inputs, for Example:

If String control wired to selector equal to C control then do the C tab content.



I have experienced similar problems many times when I need to compare the selector to a dynamically changeable variable.

Of course, there are other solutions but I think my solution may be useful.

The current way to bind many shared variables to an OPC client, is through browsing a tree and selecting.

This is very time consuming when you have hundrends or thousands of tags to bind. Specialy if the all the tags are not in the same path.

A better way, is to bind the variables, by simple text.

Example: We will insert the following text





and LabVIEW will automatically create 3 variables, bounding to those addresses (with the same name, prefered). Many OPC Servers supports this type of address.

Note that the true path of A1M01Z1 could be something very big, like:

My Computer\OPC ABB.lvlib\_OPC1\[Control Structure]\Root\NETWORK 1\Nodecm3\Extended Process Objects\MB300 AI\A1M01Z1\VALUE


This way you can add thousands of items in minutes. It is quite easy for the R&D team to implement and will help many professional engineers.

Most probably, this idea will not accept many kudos, but i think R&D must consider to implement this.


(this was discussed with NI technical suport, Reference#3279019)


Thank you all, for reading

alternative flavor to the current text type control/indicator...


analog clock.png



Provide  Stop option if camera not found in IMAQdx open Camera. In loop condition not able to stop vi




I know this idea has been coined already in A new head-controlled while loop, though it was closed becasue it didn't receive more then 4 kudos. That was 3 years ago and I didn't get any vote because I wasn't aware this post was out there. I'd like to re-open the discussion. Or for how long do we close suggested topics because at the time, there was not enough interest? It is not al that difficult and yet we are 2019 and NI still didn't solve this (as well as taking the square of a united input doesn't square the unit).


I have been programming a lot in LabVIEW and generally love it, but I also find it quite frustrating that you can not do the classic "check condition first, then run". I alos find the classic arguments not valid.


Some argue that it is easily solved using a case structure and while loop, which is not equivalent. One solution is to put the while loop inside the conditional loop, which forces you duplicate the conditional code and good programmers don't like duplicate code. (You could create subVI though, but that is also creating a lot of overhead for both the programmer as the program at run-time). Another solution, as some suggested here, is to put the case structure in the while loop, but then if you are indexing the output, you output a array with one element, whereas you probably wanted to output an empty array. In this case you can work with conditional terminals but that is also a lot of overhead and there is even a bug in LabVIEW when you output multidimensional arrays in this way that are empty and later on try to iterate over it, a for loop will execute the inside of the for loop, although the array is "empty".


I also find the argument that it is a rare case not compelling, I myself experienced this often while programming and the whole sense of a while (or conditional for) loop is that you don't know beforehand how many times you will have to iterate it. So it might be as well that you don't even have to iterate it a single time. That sounds reasonable, no? Otherwise you would use for loop. It is actually the other way round: the classic "do while" is a rare case (that's why textbooks first learn the while loop).


I also don't agree with the fact that the way LabVIEW works, it is not possible. I understand that you need a value for non-indexing terminals, but that would simply be not supported in this type of loop. A "check first then run" kind of loop would only work with iterating terminals (which can be empty) and shift registers (which can take up the value it was initialized to).

A seperate part of the loop's body must be reserved for the conditional code (for instance a rectangle that is fixed at the left underside of the while loop rectangle), just like in most languages where you have to write your conditional statement in brackets as part of the loop statement...


This type of loop would also solve the problem that you often have to delete the last element of your indexed array because the condition for which you probably wanted it, was no longer true (but the loop has excuted first after deciding that).


Lastly, it would give new LabVIEW programmers that come from any other language more familiarity with what they know. As this is reasonably a rather big flaw in LabVIEW (see argumentation above) that is some common and basic in other languages and you are likely to stumble on quite soon when you start experimenting in LabVIEW, it might just make you turn around right away, as it was almost the case when I first started programming in LabVIEW and didn't know how the rest of the language and environment is very beautifull and well designed.

Molte applicazioni VI sono utilizzate per testare oggetti simili, ma con i valori dei controlli (panel controls) diversi, adattati per ogni tipo di oggetto da testare.

L'idea è di sviluppare due funzioni, la prima che salvi in un file, ad esempio .INI, tutti i valori dei controls utilizzati nell'applicazione, in un file a cui è possibile assegnare un nome  diverso per ogni tipo di oggetto da testare.

La seconda permette all'occorrenza di richiamare il file specifico per il tipo di oggetto da testare e caricare nei controls i valori salvati nel file.

Tali funzioni dovrebbero essere molto simile a "Make Current Values As Default" e "Reinitialize Values to Default", solo che al posto di salvare i valori nell'applicativo li salva in un file.

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!

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)

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

Here is my idea:


When searching for something in quick drop, you should be able to press shift and double click on an item and have it either insert it onto current wire(s) or replace the current node.

QD idea.png


Background: I usually either use a shortcut for the exact thing I'm looking for or else use the arrow keys to navigate down to it and then press ctl+p or ctl+i. But in some cases I am trying to insert or replace a node I don't use often and it might be near the bottom of the list. It's more convenient to use the mouse to click on it rather than a bunch of down arrow presses. But then I have to move my hand back to the keyboard to do ctl+p or ctl+i, which is not convenient. It would be nice if I could just press shift or some other modifier and double click and it would automatically insert or replace (I think it could figure out which to do by context).


Edit: I realized that the shift key already means something because it modifies how the insert works (whether to insert on each wire or onto both wires). Therefore I would propose a different modifier key, like alt+double click inserts or replaces, and shift+alt+double click inserts or replaces with shift modifier.


Hello forum


Wouldn't it be nice if we can add W10 IoT Enterprise PCs as Embedded Targets, where we can create VI executable and set it as startup programs and once deployed, the target will be automatically configured to: launch the startup programs with Embedded Enabling Features (EEF), Enhanced Write Filter (EWF), Hibernate Once, Resume Many (HORM) and File Based Write Filter (FBWF) but on different volume; as presented in NI Week TS2361 & TS8562 slides.



Subpanel invoknode is not duplicated on block diagram by clicking subpanel on front screen with ctrl+dragSubpanel invoknode is not duplicated on block diagram by clicking subpanel on front screen with ctrl+drag

Copy paste of Sub Panel from the front panel by clicking with ctrl+drag is not working as intended. same things happens with ctrl+c & ctrl+v action.
For the two front panel controls(Sub Panel) there should be two function(invoke node) mapped on block diagram. which is not in the case of copy paste of Sub Panel.
We have to manually put Sub Panel from the control pallet, and the name of the Sub Panel is not
auto incremented like other controls like Numeric..Numeric 2, Numeric 3.

Tested on LabVIEW Version 2018.0.0 and 2018.0.1