NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

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

Progress Terminal for FOR Loop

Status: New
by Member smmarlow on ‎09-02-2010 10:58 AM

Add a progress terminal that outputs a 0-100 value representing %complete for the loop.  The terminal can be enabled/disabled like the conditional terminal.  The compiler would discard the code behind it if it is not used.




trim whitespace

Status: New
by Member stbe on ‎09-02-2010 08:56 AM

The current version of Trim uses regular expressions that are quite slow, but not needed since only simple search and a substring function is desired.

Therefore, I suggest to throw out the regex functions and replace them with G code looking for the same whitespaces (or even extend the selection to the openG variant).

I use the presented version within all my string processing functions, but many shipped VIs (especially the NI_LVConfig.lvlib) uses the trimming functions a lot. Since I do a lot of config files, this starts to be the bottleneck of the total LV code.




left-trim sub-VI:



right-trim sub-VI:



Performance metrics suggest speedup of about a factor of 15 for short strings and even more (>35) for longer strings.

if a control definition is missing we can replace the new control by coping the new control to clip board and pasting on top of the control. This preserves the wiring of the control on the connecter pane.


Similarly we can have the option to replace the missing VIs (?) by coping the new VIs in the clipboard and pasting it or

add an option on in the replace menu like replace from clipboard, and it will preserves the connections.  


Event Structure Current Frame Indicator

Status: New
by Active Participant Broken_Arrow on ‎09-01-2010 08:49 AM

An Event Structure Current Frame Indicator would allow easy troubleshooting and/or feedback, especially useful when frames are accessed by dynamic events.




Auto Suggestion on placing front panel objects

Status: New
by Member sridar.m on ‎09-01-2010 05:42 AM

Auto suggestion on placing front panel objects


When we place control or indicators in front panel, suggestion as shown below will make easier to arrange front panel objects neatly










The Registry Settings within the Build Spec from an installer is using fixed values only.


It would be nice to have somthing like varaibles that contain the information that are entered on the page
"Productinformation" in the settings window from the installer.


Productname -> %productname

Productversion -> %productversion

User selected Path for installation -> %installdir


This would allow something like this:




The values {%productversion} etc. will be replaced during the setup with the real values. The %installdir contain

the selected installation dir from the user.


Use a modifier key (shift or some similar) when floating over SubVI terminals and wires to see a tip strip with the data type (at least numeric Representation). 




Add a new Value (Signaling) value to the source output of events to distinguish between manual user actions (LabVIEW UI) and Value (Signaling) property node writes.  I realize the property node is part of the LabVIEW UI, so front panel edits and Value (signaling) write both produce a souce value of 0 (LabVIEW UI), but there still should be a way to distinguish between the two.  I often find myself wanting or needing to handle the value change differently based on whether or not vlaue is input manually or whether it originated from a Value (Signaling) write, as when a program is running in manual, or "auto" mode.




Maintain Mutation History as part of Enum Type Definition

Status: New
by Trusted Enthusiast ‎08-30-2010 11:27 PM - edited ‎08-30-2010 11:32 PM

This Idea was spawned from my quest for the über-migration experience when upconverting previous versions of enum data to the most recent version - in other words, providing backwards compatibility for data sources (networked clients/servers, databases, files...) that use a previous version of an enum. 



When you flatten an enum, the result is the only the numeric value of the name-value pair. Once flattened, an enum is indistinguishable from a vanilla numeric, containing no additional information:


22751iAAC1E6C59DDD7753            22747i41FF880474AA8369

(Yes, the snippet works in 2010, even with the cameo, but it's slow because the "Favorite Scrabble Word" enum has 47k+ items)


Looking at the flattened value, the first 4 bytes (00000001) represent the value of the I32, the next two represent the 6809th enum element (1A99), the next two represent the decimal year in hex (0797), and the final two bytes represent the birth month enum index and day of month respectively. That's all the bytes there is - 20 hex nibbles of flattened data to describe the value.


Storing this data structure as-is will be problematic if the type definition of the Scrabble Club Member ever changes. Fortunately, a typedef can be converted into a class, and the class definition will natively retain data structure mutation history, meaning flattened object data can be upconverted from previous versions. Cool!




Above, we can see that if the data structure is converted to a class, the red-underlined represents byte-for-byte the same information as the flattened cluster, but with flattened classes there are additional goodies buried in the data, such as the version of the data underlined in blue.


From Preserving Class Data:


"LabVIEW, as a graphical programming environment, has an advantage over other programming languages. When you edit the class, LabVIEW records the edits that you make. LabVIEW is context aware as you change inheritance, rename classes, and modify private data clusters. This allows LabVIEW to create the mutation routine for you. LabVIEW records the version number of the data as part of the flattened data, so that when LabVIEW unflattens the data, LabVIEW knows how to mutate it into the current version of the class."


But what if you mutate one of the enums, by adding items, removing items, rearranging items, or renaming items? Now you're in a pickle, because Enums currently do not store mutation history as part of their definition.



Consider the simple enum, GreekLetters, as part of a project developed by So-So Engineering, Inc. The SSEI developers launch the code into production with version 1 of the enum: v1: { Alfa, Betta, Hero, Delta } (The So-So engineers aren't too good at Greek, but so-so engineering brings home the bacon at SSEI).


Throughout a long development cycle, every few months this enum is mutated to account for mistakes, new features, or obsolete features:
  1. v2: { Alpha, Beta, Gyro, Delta }
  2. v3: { Alpha, Beta, Gyro, Delta, Gamma }
  3. v4: { Alpha, Beta, Delta, Gamma }
  4. v5: { Alpha, Beta, Gamma, Delta }
The SSEI developers pounded out code in blissful ignorance until v4 when the app started outputting thingamabobs rather than whirleygigs. 
Their superstar programmer - boasting his shiny CLAD certificate he had been toiling for 3 years to obtain - realizes the previous versions from persistent data logs were being interpreted incorrectly. With the new v4 enum, v1 data with index 2 is now being interpreted as "Delta" instead of "Hero", and v2 data with index 3 is now "Gamma" instead of "Delta".
v5 comes around with a homebrew-upconverting-state-machine-mutater, and continually ranks higher as nastiest code the guys at SSEI have ever seen as they slowly discover Epsilon in v6, Zeta in v7, Eta in v8...

I propose that this revision history, or mutation history, be stored with the control type definition of the enum itself. Further, a flattened enum should include a four-digit version (like classes) in addition to the flattened value.
This Idea may be manifested as a new data construct altogether - the 'Enhanced Enum' or the 'Enum with Benefits' :smileywink: - or more elegantly it could be included as a new flag 'IncludeVersionHistory' in the existing enum construct.

As a final note, even if you think you're immune to this problem since you don't write enums to persistent files to be read by future versions, you're probably affected. A subVI that uses an enum BD constant will improperly upconvert to the most recent version if it is not in memory while the enum goes through multiple mutations - say a rearrange and rename - that cannot be implicitly determined without explicit mutation history.
If that explanation does not make sense (hey, it doesn't even make sense to me), just ask yourself this question: "Do default values of controls and BD constants sometimes get screwed up after rearranging, adding, or renaming enums?"

Finally, while you're excited about the Enhanced Enum, also get excited about the Enhanced Enum supporting sparseness and different datatypes. Feel free to post questions/comments/insults in the comments section below or on the original thread.



Events Registry "Unbundle" Node

Status: New
by Member smmarlow on ‎08-30-2010 05:27 PM

Currently, there is no access to the User Event references in the Dynamic Events Registry reference.  If you have a lot of user events, you either have to bundle the references together into a cluster, or have many wires through the program.  My proposal is to add a "Registered User Events" node that allows the programmer to "unbundle" the registered user events references.


Also, the Register for Events node should change the User Event label to the user event name when a user event is wired to it.  Finally, there should be some mechanism to access/control the event queue programmatically, perhaps an "invoke node" coupled with the ability to create a reference to an event structure.  This invoke node would allow the user to flush the event queue, or perform other operations on it, etc.

currently, Invoke node cannot change parameter order, so wires are twisted and It not looks good.


Suggest: Invoke node supports change parameter order, so code will looks clearer.




Local Variables in stacked sequences

Status: New
by Member sjunge ‎08-30-2010 03:18 AM - edited ‎08-30-2010 03:20 AM


In a stacked sequence a local variable is only on one side (normaly to the right).

I think many of us are programming from the left to the right, so please


1.) add a second output of the sequence on the other side, or

2.) allow to move the output on page 1 to the left, but independed of the input on page 0




SGL (and CSG) support for Math functions

Status: New
by Active Participant GregS on ‎08-29-2010 11:06 PM

While the intrinsic Math functions all support EXT, DBL and SGL, few of the remaining Math (or Signal Processing etc) functions support anything except DBL.  For many cases, using SGLs is sufficiently accurate, while using less memory and often being faster to compute.  While some functions are implemented solely in G (and therefore it is easy to create an SGL copy, though not so easy to integrate in a "polymorphic" way into the existing menus), most functions call a DLL routine.


I suggest that SGL (and CSG where appropriate) be supported for all Mathematics functions, including Signal Processing, and the Advanced Signal Processing Toolkit.  Is there anyone else who would make use of these if available?


Note: two "addons" have been released by NI which begin to address this.


Single-Precision Basic Linear Algebra Subroutines (BLAS)

It would be useful to have the possibility to save own snippets like a modified state machine and to access those snippets easily.


With LabVIEW 2009 and 2010 you can use the code snippet function and save snippets as PNG-file. But I have to use the Windows Explorer or something similar to manage them.

In LabVIEW you can only save templates but it's not possible to insert own block diagram snippets to an existing block diagram.


Reset properties of front panel elements

Status: New
by Member Matthias_H on ‎08-28-2010 08:54 AM

While playing around with property nodes it is sometimes the case that you set some properties and want to reset the front panel element after some tests

You place a boolean front panel element and set the property "blinking". Later you decide to remove this property node but the property is still saved in the front panel element.
It's not possible to reset the blinking property with the properties dialog.

I would prefer having an item in the popup menu of the front panel element like "reset properties to default", which resets all properties of this specific element.
Without this feature I have to replace the front panel element with a new one.

0 Kudos

GOOP - Need a new kind of "variant" for inherited functions

Status: New
by Member WG- ‎08-27-2010 04:57 PM - edited ‎08-27-2010 05:01 PM

Currently I'm busy with GOOP and I came across the following problem. 


I have a validator class. The purpose of this class is to validate data. The validator class as a number of childrens...


Validate IP address

Validate string length

Validate inRange number

Validate Alpha


The main, validator, class has a function called "valid?" This function has 3 inputs and 3 outputs



- Object

- The data that must be validated

- Error



- Object

- Valid?

- Error


The children classes must inherit this function and overwrite it. Now the problem is is that each of the above validators have a different datatype which must be validated....


Validate IP address has a string as input

Validate string length has a string as input

Validate inRange number has a number as input

Validate Alpha has a string as input


Now you might see the problem. To get the children to inherit the function from the main, validator, class the connector pane must be the same as of the datatypes... This means that I have to choose in my main function to use a string or a number as input... This is something that I don't want... I want to be able to select a datatype called "yet unknown datatype" in my main "valid?" function in the main, validator, class. So that I can use any datatype input in my children that is suitable for that implementation. 



My idea is thus to create a new kind of datatype which sort of represents "any kind of datatype known to labview" which can be used in functions of a main class that are inherited by its children, which are all using a different input datatype.


ps. Now you could maybe suggest why not use a variant datatype? Yes this is possible but the problem is;

- I would have to cast the data back

- It isn't very neat programming, the variant solution is in my opinion more a kind of hack to make the code work.


pss. Yes but if you would do this... then...

- Yes there are proberbly a few more work arounds thinkable, such as creating two "Valid" VI's one inherited (Valid?), one unique of the child (_Valid?), but these are in my opinion still workarounds and do not really provide the functionality that is needed. Which is pretty common in OOP languages.


psss. if anyone knows a better title for this described idea let me know it! 


Allow VITs and CTTs to Behave Correctly As Merge VIs

Status: New
by Active Participant jgcode ‎08-27-2010 12:08 PM - edited ‎08-27-2010 12:14 PM

Currently if you drop a Merge VI containing VITs or CTTs from the palette onto you BD it is dropped as the Template not an Instance of the Template.

Obviously we want the latter.


It would be nice if this was handled by LabVIEW so that we can centralize an API with Templates through the palette.




This is related to this Idea.


See here and here for side chatter (and the original Idea).


Additionally, to top it off, this will be great when the outstanding CAR to fix up a bug with FP Object positions in completed :smileyhappy:




System Containers

Status: New
by Knight of NI on ‎08-27-2010 11:49 AM

As already mentioned here long ago, there is a need for system containers.


Most of my front panel uses system controls/indicators and I often use arrays and clusters. The currently available containers (modern, classic) simply don't match the overall system style.


The system palette needs a "System Array, Matrix & Cluster" sub palette.


A quote from my old comment says it all:


For example, there is no "system" array container (with a correctly colored frame and a system spin control as index control) or "system" cluster container (could look similar to the system radio button control).


Allow 0pixel size splitter bars

Status: New
by Active Participant crelf on ‎08-27-2010 10:03 AM

We've all seen the demo that shogg did where he set the color of his splitter bars to the panel color so they disappear at run time, but what if the splitter goes over background controls that you want to persist between panels?




It look slike the smallest i can have my splitter bars is 2 pixels.  I totally want them to show up in edit mode, but I'd like them to be 0 pixels wide in run mode (selectable, of course).

Currently Templates are not allowed in the Tools Menu, at the moment they just get ignored.

A fast way to access Templates would be just to select them from the Tools Menu.

Selecting a Template from the Tools Menu would create a new instance in memory.



See here and here for side chatter.

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
Idea Statuses