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 Kudoed 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
0 Kudos

I'd like to see something like a conditional disable structure that would be sensitive to fields in an .ini file at runtime, not compile time.


My problem is that I have an application that can access many different third party cameras. For this application to work every VI that accesses a camera specific .dll function must have assess to that .dll or I get a broken VI. When I compile the VI I have access to these .dlls but when I build an application.exe and distribute it I only want to distribute the .dlls for one of the cameras. If I could distribute a .ini file with the application.exe that indicated which camera the drivers were installed for then the application would disable the code for all the other cameras and the VI would not break.

Thank you,

Chuck Lippmeier

0 Kudos

Using the LabVIEW 2009 Build Spec (as an example) allows you to add a Destination to a Library which is very handy, as it means you can namespace VIs at build-time.


I would like to take this a step forward and then be able to set that new Library as a Sub-Library of another Library that already exists in the Project.

I would then want to be able to set the scope of this Sub-Library as well (relative to its now, Parent).


This combined with my Locking State Idea would allow be create a Distribution that would hide and protect a Support VI Library

As the Sub-Library would be Private Scoped (from above) and the Parent Library would be set Locked (does not show Private Members).


I currently can implement this using Scripting but it would be nice to have it native.







0 Kudos



What I really would like to se implemented as a future feature is a 'Search 1D' with the option to do a case insensitive search.


Usually I just plug a "to upper case" vi on both array and search string inputs. It would be nice to be able to select it right on the vi instead.


The functionality should work as with the case insensitive match in the case structure.





0 Kudos



I need a vi which will convert PNG file to GIF file. i could find a vi which is not in palette, do this. But the output GIF file is in uncompressed format. So the size of the file is very large. And also it is not working when i build the application as EXE.


It will be really helpful for me if this feature is included in the next release of LV.





0 Kudos

It would be beneficial if nodes had the ability to retain data from their previous execution. Along with "Use Default If Unwired" it would save memory allocation and coding time if there was a "Use Current Value If Unwired" selection which would retain the node's value and pass the last executed value. 


 Use Current Value If Unwired.PNG

This figure illustrates one application where "Use Current Value If Unwired" would save memory and increase performance instead of using multiple property nodes or local variables for retaining the output data. It would also eliminate extra wiring in every case this node is not used.

0 Kudos

Create a VI to read the config from string instead from a file for in memory configuration.


Also create a VI to read out the config as string.




0 Kudos



in LV2009 a new set of VIs have been published for working with configuration VIs. They are now part of config.lvlib. But some VIs of config.lvlib are marked private, therefore I cannot use these VIs as Sub-VIs, if the calling VI is not part of config.lvlib. This is bad (at least for me), since I have written some tools to load a configuration directly from a string and not from a file. To do this in LV2009, I need these private VIs, which I cannot use without changing config.lvlib.


Therefore I suggest to make all VIs of config.lvlib public. In fact, is there a good reason, why these are private in the first place?




0 Kudos

When developing LabVIEW automation tools, I miss a way to list the controls connected to a VI's connector pane. That would make it possible for the user to better select which controls to set before calling a VI (dynamic VI call).


An "IsOnConnector" property on a control reference would be very useful. Or better; a property returning an enum with one of the four values: "NotConnected", "Optional", "Recommended" and "Required".


Another solution could be a property like the Controls property on a Panel reference, but only listing the controls on the connector.


0 Kudos

When browsing data in MAX (Historical Data Viewer) via the cursors function the time shell be added although after an full minute, hour or day. At the moment when incrementing from 19:59:59 by one second the time will be 19:59:00. Shouldn't the expected result be 20:00:00?

0 Kudos

Via the Historical Data Viewer it is possible to export the citadel data to text (compare screenshot). In many cases it is necessary to export only the real datapoints without interpolation (like the read trace VI supports) to avoid an incorrect representation of the recorded data.

0 Kudos

In the LabVIEW development environment it is possible to separate the shared variables via virtual folders. In cases with more than 100 variables it is very difficult to keep a structure at runtime. Therefore it would be a great improvement for us to implement a new hierarchical level (name of the virtual folder) to ensure a well-arranged structure also in the runtime. This structure should be kept in the Shared Variable Engine and also in the Citadel Database.

0 Kudos

I would like to see and option to use our development system that is enabled by a hardware key. That way, you can put it on any machine you want for development without worrying about licensing. A lot of LabVIEW applications are one of a kind systems, complex systems. The programmer does not always have time to add a lot of code for all the errors you can encounter. With the debugging tools in the development system, debugging would be much easier than trying to debug a built application. This would enable the owner of the software to load his system on a target machine and when he is done developing the application, he can build it as normal. It would be desirable to also be able to use you key for connecting to a remote site, using remote desktop, pachyderm, etc. This would greatly help for field support of application. It would also make it easier to support previous versions of LabVIEW, as the project and software would be on the target machine. Changes that could take days could now be done in minutes.

0 Kudos

If you use the NI proposed way of creating Sub-VIs for functions (which is good), debugging soon becomes a nightmare with every VI opening two windows, one of which is mostly not needed (the front panel). It would be great if LV gave us an option saying "Do not open front panels when debugging", which would only open the block diagram. Instead of the front panel you could only offer a list of all input/output controls (and maybe their values), and you could put this list in the same window for all open VIs (in some organized way - maybe similar to probe window). That way all front panels would only take up one window instead of many.

0 Kudos

I wasn't able to create a multi-line comment.  Is this possible?  If not introduce that structure...

0 Kudos

I think there should be a way to reinitialize a stacked shift register to the originally initialized value so you can clear out the contents of every iteration all at once.  For example, the code below, implemented with 4 individual shift registers:


 multiple shift registers.PNG


Could be implemented with 1 stacked shift register with a reinitialize terminal:


stacked shift register with reinitialize.PNG 

0 Kudos

I would like the maximize button removed from the FP & especially the BD.  I typically work with many VIs open at once and I find it very annoying to open a subVI that consumes my entire desktop with a lot of white space. This is true of the FP and the BD.


Lets be real - your code is not that important.  The one except might be the main GUI.

0 Kudos

At least numeric controls and string controls loose focus after pressing enter. This is especially unpractically when navigating by key. The focus should be held on all controls as it is on boolean controls.

0 Kudos

Classes in LabVIEW are a great step over (and finally, with LV 2009 them start to work...) but there are still two 'holes'


Abstract methods. 

It would be great to have the possibility to define abstract methods and interfaces. Now I'm forcing an error into the error out indicator to notify the usage of a method not yet defined but it would be better to make the compiler to recognize the usage of abstract methods during the design time. One way to define abstract methods could be the introduction of a new entry in the 'class menu' and allowing to define them just in term of front panel (block diagram not available).


Class duplication.

An object is duplicated on each node, so is not easy to work into parralel loops on the same instance. To use the same instance I have used references, but it is not so easy to use (not as the 'normal' wires) and it hasn't the same performance (working with reference is heavier than working with instances). It would be great to introduce a mechanism that implements the convertion from instance to object, something likes a standard 'getReference' and 'getInstance'.

0 Kudos

it would be nice if we could copy teh changes from one vi to another while comparing two VI's