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!
Showing results for 
Search instead for 
Did you mean: 
Post an idea



I'm about to upgrade from LV8.2.1 to LV2013 and then there is a lot of unsupported properties and methods in the new version.

It would be very nice to have the possibility to find those unsupported stuff.


Actually NI seems to need that function too. smileywink:

Take a look at this thread I made a while ago.



regards Bjarne

Download All

 Getting a value change event on a shared variables seems to me like something that ought to be expected "out of the box" in LabVIEW.  Polling shared variables for changes is taxing on resources, and such an architecture is generally frowned upon by NI and the LabVIEW community for things like front panel interactions and the like.  Why, then, should we expect to pay extra to deploy applications which such an architecture for interacting with shared variables?


I completely understand the extra license for the DSC run-time, as there are numerous other terrific tools included.  It just seems to me that the SV value change events are one thing that should be freely available for deployment to everyone already paying for the application builder.



To be honest, I am not entirely sure what that means. Only that my IT department says NI downloads do not have a valid signature and the firewall blocks them. Currently we are working through this "" , but I am not convinced the answer is there for us. I am able to download files from any website that I currently use here at work so I don't understand why NI downloads would have a problem. By the way, this is using the NI downloader or using manual download, neither method works. Using other browsers yeilds nothing either. Cruising the internet for similar problems came up with "Software Publisher’s Digital Certificate", is it possible NI's isn't valid or something?

Anyway, seeing as how internet security is just going to get tighter and firewalls more strict, I don't want hokey solution that will just break with another update. Anybody got an answer for this delima?


NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.


My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

Delete option in Context Menu.png

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is uncomfortable.


So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past...:smileyhappy: He! He! He!

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

Delete option in Context Menu.png

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is non comfortable.


So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past...:smileyhappy: He! He! He!

To make easier the distribution of .lvclass, it would be interesting to create packed lvclass (.lvclassp) like lvlibp for lvlib. A second idea is the possibility to call lvclassp 's Methods in Teststand.

The NI Volume License Manager has a tool to create a volume license installer.


If you want to include Drivers you have to copy them to the installer folder _src\DriverDVD and then modify the nisuite.xml file (depending on license server you run)


There needs to be a simple way to say add NI disc to installer folder. Or at the end of creating the installer it could ask if you want to include other discs.


This should work for adding the driver disc and other extras like the Xilinx Compilation Tools, etc...


That way you can easily put together a full LabView Development install location for users.


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."

As software versioning becomes more and more popular also the automatic building of source code becomes more and more interesting.


Right now in our company we are using GIT and JENKINS for C-code material as our versioning and automatic build tool. As soon there is something being checked in and pushed to the main repository the builder gets notified and tries to build your source code having the output available somewhere.


As we are having many users around the globe these tools obviously run on a virtual machine or server somewhere.


Right now there is no option in buying the application builder seperatley and control it via command line. The only option is to put a complete development environment on there which is useless and a waste of money.


My request would be to sell the application builder seperatley for these purposes OR figure out an alternative way for doing this in a professional and neat way.


some usefull links:

Right now in labVIEW the plots can be exported into excel and can be saved into different  image formats (*.png,*.jpeg,*.eps,etc,.). In addition to the other properties it would really a very cool and excellent option to save the plot data as a LabVIEW figure with an extension "vifig" (*.vifig). The idea here is when the  plot is saved as LabVIEW figure the tester with the help of an interactive tool or some thing like this reload the *.vifig to view, change the graphic object properties , maipulate legend, xaxis label, yaxis label so on... and finally save.


Let's assume a situation where the user wants to analyse the data (zoom in, zoom out, find delay etc.,) and change few properties the the data who doesn't know LabVIEW and he needs to use another programs like origin, excel etc. This could be done very easily witht he help of an interactive tool. Unlike LabVIEW, the softwares like MATLAB, Origin has such a pretty useful option. 


Thank you.

Hi !


Often dealing with old code it's always a pain to install old versions of LabVIEW to get the code compiled the newest LV version.

For example, porting code made in LV 5.0 implies converting first to LV 7, then convert to LV 2009, and finally convert to LV 2013.

You then have to install these version, licences, ...


It would be nice to have a service on website from which we could send a zip archive containing the project to convert.

Then selecting the target LV version, a could service could unzip and compile the code across all versions of LV to have the code matching the requested version.


As much bug as suggestion, but since it's been this way for a bunch of years i assume it's a "feature"


I just had a project in which i defined some DAQmx tasks in the project, but in order to get them installed on the target i need to:

1. Export the tasks from the project

2. Select import MAX tasks in the installer which starts and forces me to run a new export.

3. Re-export the tasks from the project to overwrite the max export ...

(yes i could have skipped step 1 had i known the cumbersome mess)


Why cant i simply select a configuration file to include in the installer?

Why cant i select/choose tasks defined in the project?


If i want to avoid the exporter i need to edit the project xml, that's not acceptable.



Allow to simply select a configuration file to include in the installer

Allow select/choose tasks defined in the project



This is a real pain for me and I think this should not be considered expected behaviour of LabVIEW. But since I have been told it is I am posting this as an idea for the Idea Exchange. Let me explain:


Imagine you build an application which makes use of a large number of files (images, text files, etc) and you would like to include these in the build specification of your application. Imagine you want the files to go to various different custom locations on the computer (some in documents, some in a folder on your desktop, some in another location... the list goes on). I have such an application and it includes about 25 different folder locations I had to insert manually as destinations for the files. This is fine, I expect to do such a thing and it was simple enough (although time consuming).


Now comes the pain:


I now want to build an installer which uses this EXE build spec. If I use the EXE build spec in my installer build spec the result is to place all of these dependent files in the same folder as the installed executable, not the locations I defined in the EXE build! This means I have had to go back and create a new EXE build spec which contains no dependent files (so that it compiles without placing files everywhere) and then back to the installer to use that EXE build and then define all the location yet again! This has been super time consuming.


Upon discussion this is apparently expected behaviour as installer build specs are seperate to the exe build specs....... except am I not right in thinking the installer build spec relies on you having an EXE build spec???


So currently the situation is this: I have to have to have an EXE build spec containing the custom destinations which I can build and use to test my application. I then also have to have an EXE build containing no custom locations which when built is useless since it is missing dependent files, but purely there to then create the installer build specification which I have to define all custom locations in again.


My proposal is simple: When you create an installer that uses an EXE build spec with custom locations for files it should replicate those locations in the instaler. Simples!


Note: If this was super confusing download the attached project and see for yourself. (LabVIEW 2013)

Right now, we can build an installer which embeds other installers (e.g. the LVRTE).  So we can distribute the installer and allow our customers to install everything they need using one installer.  This is great.  But I find that it sometimes disturbs my customers when they see that my application is also installing other things (i.e. LVRTE, DAQmx, etc).  They are curious about the "3rd Party Components".  I totally understand this.  When I download an installer, and see things like "Click here to also install Google Chrome" or Google Earth or some other spyware garbage, I am immediately suspicious.  Or worse, when I am not even warned about.  Bundling other installers is a common way to spread adware.  



- Bundling third party componenets into an installer is suspicious to many users. 

- Bunlding extra installers also makes the un-intall process more complex (you have to uninstall things the extra stuff in a different step).

- Current method of bundling extra installers does not inform the user about all of the components being installed



So my suggestion:  Allow these components to be bundled (i.e. hidden) in the application directory.  I believe this is already possible with other run-time engines like the Java Runtime Engime.  And I see that something similar is possible with LabWindows/CVI (see here), though I have never used LabWindows.


I guess another way to do this is just to somehow hide the extra stuff from the user.  Do a silent install of all the 3rd party componenets.  But I feel like that is a bit devious, and might piss off some customers.



I have some suggestions for the script that comes with the OS X installer:


1) Copy it on installation into the main LabView application folder so that users don't need to find (or redownload, in my case) the original installer just to remove a seven-day evaluation copy (grrrr....).


2) Lines 85-88 need modification. They read:


[from the file]

echo "pid=\$( ps -axww | grep nisvcloc | grep -v grep | awk '{print \$2}')"
echo "if [ \$pid ]; then"
echo "sudo kill -6 $pid"
echo "fi"


When I ran the script, the $pid was omitted in the screen output:


[from the screen output of]

pid=$( ps -axww | grep nisvcloc | grep -v grep | awk '{print $2}')

if [ $pid ]; then

sudo kill -6 



It looks like the "$" should be changed to "\$' on line 87:


[Corrected line 87 for the file]

echo "sudo kill -6 \$pid"


3) For my OS, there is an error in both the documentation lines 85-88 and the associated code on lines 189-193: the process ID is associated with the first variable of the grep expression, not the second. The second variable returns the TTY for the process, which for nisvcloc is given as "??".


[from the file]

echo "Stopping the NI Service Locator..."
pid=$( ps -axww | grep nisvcloc | grep -v grep | awk '{print $2}')
if [ $pid ]; then
sudo kill -6 $pid


[from the screen output of]

Stopping the NI Service Locator...

kill: illegal process id: ??


[Corrected line 190 for the file]

pid=$( ps -axww | grep nisvcloc | grep -v grep | awk '{print $1}')


[Corrected line 85 for the file]

echo "pid=\$( ps -axww | grep nisvcloc | grep -v grep | awk '{print \$1}')"

I have LabVIEW installed on two computers - a desktop computer and a notebook computer. Neither computer can access the internet. When activating my products, I must select the product to activate and then enter several pieces of information (name, s/n, computer ID, ...) for every product. Repeat for 2nd machine. I would like for the web interface to retain the above information so I don't have to enter it many times in order to collect the keys for all of my products.


Another option would be for the web interface to return licence keys for all products registered (or give me check boxes to select products to register) to the given s/n so that I can copy/paste them to a file. I can then move that file to the target computer and activate everything.


So, having a new computer and installing the 4 versions i currently need i ofcourse missed to reinstall DaqMx after the last and most important LV install. After alot of time i managed to get hold of a disc, ofc slightly lower version so i first have to uninstall my current DaqMx ... this cost alot unnessecary time, when e.g. MAX should be able to add/complement itself to installs.


When i run the installer, it feels which versions of LV has Daq and which doesn't, it'd be great if you could add/complement Daq to LV's without having to reinstall it!


If this is best handled by MAX or some DAQ-installer i dont know, but as MAX feels like a hub it sounds logical to add some Update/Add/Attach DAQ-function to that.



This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.


To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.


Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.


My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.


Typical phone exchange yesterday:


me: "just click my installer and install the program"

him: "OK, done."

me: "now run it."

him: "OK, ...... error about 2013 run-time engine".

me: "OK, install the run-time engine using the link I sent you in the same e-mail".

him: "clicking the link to go to the run time engine page....

        (..30 second discussion to decide between downloader and direct download...)"

him: "click..(wait for it!)... .it wants me to register..."

me: "OK, let's forget about that. come down to the lab and I will do it for you."


End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.


While gazillions (:D) of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.


I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to "[] I don't want to register at this time, just download the run-time!".



Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers. 😄

Yup,  Upgrading LabVIEW versions takes a day.


The "Process" today is:

  • Install from media
  • Configure the new LabVIEW.ini
  • install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
  • Mass Compile all them......
  • Fix palatte views... and import and mass compile User.lib\ for here.....
  • Sync glyphs on the icon editor (If the link works......)
  • Add VIT's
  • Add Project Templates
  • Mass compileVIt's and Templates
  • fix "Metadata.xml"...



Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!