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

Improve that damn Licence manager!

Status: New
by Trusted Enthusiast on ‎07-22-2014 01:26 AM - last edited on ‎07-22-2014 01:39 PM by Trusted Enthusiast

As you can read in the link below the licence manager uses the MAC addresses of a computer to create computer ID used for the activation process.

The trouble is that when you use a NI PCIe 8235 (Quad-Port GigE Vision Frame Grabber) you are adding 4 Ethernet ports to you computer and any change to any of these ports (even a fix IP change of one of the ports) will change the computer ID and therefore you will need to re-activate all your NI products... As day to day users we simply cannot work that way.


The knowledge base article below explains that in such cases we can get the hard drive serial number, send it to NI and they'll give us a computer ID based on that HDD serial instead of the computer ID given by the licence manager and we can then use it for the activation process.


The point of this idea is to ask NI to improve the licence manager so we don't have to go through this issues, I think the licence manager should inform the user about what the computer ID is based on and tell him about the options (MAC address or HDD serial) and let him choose between the 2.


How Can I Change the Hardware Used for Activation of NI Software? 


PS :

and now that we're talking about improving that damn licence manager, you can refactor it to include other ideas such as :

Smartphone application to activate NI Software

Add a QR Code (2D Bar Code) Option To NI Product Activation Dialog


[admin edit]

I am copying the workaround posted by crossrulz in the comments to benefit users having these issues who find this idea:
"Here is a work around if you want to play around in the Windows registry:

In "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\National Instruments\License Manager" add a string value named "DiskOnly" and set it to "true".  The license manager will now only use the HDD serial number."

When hovering over a global variable in LabVIEW, the IDE doesn't really give us much information at the moment.  What I would like is to have the context help show me the path and filename of the global in question within the context help.  This would help debugging a lot.


And while we're at it, at least show the datatype of the global in the context help.  At the moment, the only thing shown in context help is the name of the global item selected, but I already see that ont he BD. D'oh.


That's all.


Easy toggle tunnel mode

Status: New
by Active Participant SteenSchmidt ‎07-16-2014 08:02 AM - edited ‎07-16-2014 08:03 AM



After we have gotten several different new tunnel modes, it takes quite a lot of context menu exercise to change tunnel mode on structures:




I propose a shortcut where we can click directly on the tunnel to toggle between valid modes:




I say valid modes as not all modes are valid for all tunnel data types, for instance the "Concatenating" mode isn't allowed for scalars, but is still selectable in the context menu resulting in a broken scalar wire leading to the concatenating tunnel - the toggle should perhaps skip such an invalid setting? Or maybe not, in case you're preparing to change data type and just want to toggle the tunnel first, I don't know.


Tunnels on different structures have different modes. On case and event structures the modes you could toggle between would be 'Use Default If Unwired' on/off for instance.


Am I the only one feeling there's a long way into the tunnel mode menu now?




Hello all,


This is an elaboration on a prior request by RavensFan:


When AppBuilder reports a file related error, such as error 8, could someone please provide a path?


I have no idea what's causing my file IO error, as I am running LabVIEW as a local admin and there should be nothing interfering with my path.

I can't probe a path wire in the AB method because the diagrams are understandably locked.


This is so frustrating.  No one likes to debug by guessing and it wastes a tremendous amount of time.




Thank you with my deepest respect to the AB team.





For example:



Allow seletcion of multiple VIs in "Select VI" option

Status: New
by Trusted Enthusiast ‎07-15-2014 07:34 AM - edited ‎07-15-2014 08:03 AM

At present we can select only a single VI on "RightClick>Select VI" option in Block diagram. It would be much helpful if we can select multiple VIs at the same time. Image for reference







Present MethodMultipleSel-2.png





































Proposed Method

If you have open the Bookmark Manager and
you change one bookmark, the Manager gets an "Bookmark Info Change" event and reloads all bookmarks from all
VIs in the project. The event that triggers the update is the
application event "Bookmark Info Change". At this event there is no
info in which vis a bookmark has changed. If the event would provide the info which VIs have changed,
the Bookmark Manager would be able to reload only the bookmarks from this particular vis.
On larger projects the Bookmark Manager needs minutes (Time and CPU
load) to update the whole list. The additional event data node can be an array of vi names or references.


This changes will fixed also the EventQ Problem of the Bookmark Manager. If the Bookmark Manager is open and you change several Bookmarks the manager reloads all VIs for x times because everey change generates a "Bookmakrs Info Change" Event.


Better LabVIEW Help: use F1 to go to the topic

Status: New
by Member RENN on ‎07-09-2014 03:33 AM




instead of using the right-click context menu / using ctrl+H and then selecting help,

use F1 to go to the topic




Multi Conditional Tunnel

Status: New
by Member sjunge ‎07-17-2014 01:46 AM - edited ‎07-17-2014 01:49 AM

It would be nice to have a conditional tunnel that can be extend with more tunnel.

In this example, each one has it's own output as 1D-array and only one boolean trigger.



Multi Conditional Tunnel.png


Case strucutre ctrl+scroll should display cases

Status: New
by Member 1984 ‎07-08-2014 01:03 AM - edited ‎07-08-2014 01:08 AM

Using ctrl + scroll for switching between the cases is somewhat hard to use, because when you have lots of cases its difficult to remember what is the order of them so its harder to ctrl scroll the one you looking for than to go to the case selector. Moreover if you work with bigger sized structures (which happens sometimes) you may not even have the case selector on your screen so if you ctrl scroll, you can only deduct which case you see by the visible part of the code itself. That doesnt work for me, I always go to the selector.


But what if when the user uses ctrl + scroll a small popup would appear at the mouse pointer and when the user scrolls up and down the highligh would move up and down selecting any case in the given structure?


This would highly increase the usability.


Applicable to the Event structure as well.




Active Structure Debug Indication

Status: New
by Active Participant wiebe@CARYA on ‎06-17-2014 10:13 AM

When entering debug mode (turn execution highlight on) it can be hard to see what is happening.


With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...

Parallel Loops.png


SubVI's get a green arrow when they are executing. So, could structures get them as well?


Parallel Loops proposal.png


Check file permissions at start of build

Status: New
by Member TurboPhil on ‎07-16-2014 06:21 PM

Sometimes I do dumb things. One example is that I often forget to stop running an executable before attempting to rebuild it. The AppBuilder eventually fails because the file is locked--it can't delete & recreate the *.exe file if it is actively running--but sometimes it takes several minutes before the AppBuilder gets around to checking that. It would be nice if it did the file permissions check earlier in the process, so my foolishness doesn't slow me down excessively.


Also, since the "cancel" button for builds doesn't actually do anything, even if I notice it immediately, I'm still stuck twiddling my thumbs for a few minutes until the AppBuilder *realizes* it can't complete the process....


DVR shell

Status: Duplicate
by Trusted Enthusiast on ‎07-09-2014 10:14 AM

When working with DVRs, i find it always a little cumbersome to create the DVR control and indicator for subVIs or data container (cluster, class).

I suggest to have a "DVR shell" available for front panel with no data type contained in the DVR. Dropping the DVR shell on the FP would break the VI, just like cluster and array shells already do.


The main reason for this suggestion is that dropping a data type in the DVR control/indicator already changes the DVR, so it is easy to "adapt" it to type.




Create cluster out of selection

Status: New
by Member okubik ‎05-15-2014 04:57 AM - edited ‎05-15-2014 04:58 AM

Hi guys,

I'm missing some very fast way how to create cluster out of selection. It could be done as it is shown here:


create cluster.png


I think since LV developers became familiar with Every GUI Programmer's Dream they are ready for the next step...

It would be really cool to have a custom probe that could be placed on any cluster/class wire to view the data in the cluster, but instead of being displayed as a standard view of the cluster, the labels of the items would be listed along with the data type and the current value (works for scalar or small arrays, not so well for large arrays/waveforms). The standard view of a cluster probe is shown below.




I built a custom probe to do this but found that the data type of custom probes is strictly typed and therefore I have to convert my data to variant on the vi block diagram before adding the probe, which isn't great. I've attached the code for my custom probe, and a screenshot of it below.




If variant custom probes could be used on any data type, this would work.

Could NI please consider automatically including all the items from the "Execution" category of the VI Properties editor in the help window documentation. This would make it much easier to determine if priority/execution/thread setting is correct, and greatly help with reentrancy/INLINE status. That would be really useful for FPGA development, which selects reentrant by default, when other platforms do not. Currently, a LOT of mouse thrashing is required to confirm status of all subVIs.


A Menu Entry to Clear Variant Data

Status: New
by Knight of NI ‎06-11-2014 11:31 AM - edited ‎06-11-2014 11:33 AM

I recently noticed that some of my fitting model VIs were excessively large on disk. It turns out that during debugging long ago I made the current values the default so I can run it standalone. This also meant that the data variant control contained a gigantic kernel matrix.


For some reason it is not obvious how to clear the variant (in order to be able to make the new value default and make the VI small again).


For example for the nonlinear fitting model templates, the data is not shown by default, obscuring the fact that it is the culprit for the excessive size. This also makes clearing the variant tedious ( all data...delete...right-click...uncheck show data...).


IDEA: I propose a new menu entry: " operations...Clear Data" or similar.


See picture. Thanks!



After you selected a shared var, local var, ... it should be possible to use a shortcut (ctrl+x) to switch between the read and write option


Add option to enforce vertical wire label position

Status: New
by Member jmorris on ‎06-27-2014 02:57 PM

Hello all,


I find myself constantly tweaking my wire labels so that they look like they are exactly vertically centered on the wire, rather than a couple pixels higher or lower.  They are not always created that way, and of course when you move the wire around they don't stay that way like I wish they would.


I'd like to propose an option to have LabVIEW automatically force wire labels to stay vertically centered on the wire (similar to other "snap-to" label positionings).  I know that other programmers prefer other positions, such as immediately above the wire, therefore having it snap to that position would be another option.  I'm not sure if it makes more sense to select one position that it always snaps to, or have it snap to one of a few options (like labels on controls do now).  I always use them consistently in the one vertical position, myself.


It may make sense to have the default be free-positioning as it stands today, but it would save me a non-trivial amount of time to have the option for it to be always enforced to what I think looks nice.  :smileyhappy:  Hopefully I'm not the only one!


Obligatory pictures:


Initial vertical position when I select to make the wire label visible (looks terrible!):

Initial position.PNG


The vertical position I always want it to stay in:

Centered position.PNG


An alternative snap-to vertical position:

Above wire.PNG


New palette options: 'Open VI' and 'Run VI'

Status: New
by Active Participant SteenSchmidt ‎07-10-2014 08:46 AM - edited ‎07-10-2014 09:02 AM



Currently on a functions palette item (when you edit the palettes) you have the option of placing the VI contents as an alternative to the default behavior of placing the VI itself on the block diagram:




I suggest two additional options in this menu: 'Open VI' and 'Run VI'.


Two such options will enable us to bundle help-VIs, scripting VIs and examples directly in a sub-palette of toolsets, instead of going the long almost impossible way of building bin3 files for the Example Finder.


One of many current use cases we have at GPower is the ExpressionTester in our Expression Parser toolset:




The ExpressionTester is a utility, a small application actually, that lets the user investigate different mathematical string expressions before committing them to code, and it has no use as a subVI. We feel it has the highest chance of user discovery when positioned just with the toolset functional VIs (i.e. in the palette), instead of being buried either on disk available through a link in the detailed help file, or in a Tools menu item. But to use it from the palette today, the user has to drop it on a block daigram, open the subVI and run it. And then remember to delete it again from the block diagram, preferably with CTRL+Z to avoid contaminating the undo-stack. If we could mark that palette item as 'Run VI' then clicking it would just start the ExpressionTester utility.


Perhaps palette items configured to being opened/run/content-dropped instead of the default action should have some sort of indication on it, that clicking it executes a non-default behavior?





Numeric control limits should default to "Coerce".

Status: New
by Knight of NI on ‎05-20-2014 05:53 AM

Today, when you change a numeric control not to use the default limits, it allows you to enter your new limits, but it doesn't actually respect them unless you change the response control on the right side, which can be easy to forget.


I propose that the default value of the controls should be "Coerce", not "Ignore":


Default to Coerce.png



This makes sense, because if the user unchecked the check box, they probably want the limits to coerce and in case they don't, the limits already default to the maximum range of the data type, so they can't be coerced unless the user changes the limit value anyway.


I would also suggest considering that if the Response control is set to Ignore, the value should be disabled and greyed, to inform the user that changing it won't actually do anything. I would suggest getting rid of the Response control entirely, but it can be relevant if you only want to change some of the limits.


I would also consider changing the coercion of the Increment to Nearest by default, since it's probably the most common option, but that could be debated.

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
User Kudos Count
Idea Statuses