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

We just bought LabVIEW 2010 and I noticed that there is no utility avaible for converting a function panel (.fp) to a VI.  When will this utility be available?



An acronym for one of my favorite Spolskyisms. Great article, read it.




When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.


Problems with Current Issue Tracking Platform


"Platform" is a generous term for the current reporting and tracking process:


  1. The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
  2. Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
  3. Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
  4. Relies on unreliable methods including email, FTP uploads, phone conversations, forums...

Comparing LabVIEW Issue Tracking and Feature Tracking Platforms


Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. Smiley Very Happy The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.


I want to see an analogue for Issue Tracking.


Proposed Solution


A web-based platform with the following capabilities:


  1. Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
  2. Allow embedded video screen captures (such as Jing)
  3. Allow uploaded files that demonstrate reproduceable issues
  4. Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
  5. Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
  6. Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
  7. The Homepage of the Issue Tracker should be accessible and visible through (maybe IDE too, such as a GSW link)
  8. A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
  9. Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
  10. An email-based alert system, letting you know when the status or content changes in bug reports of interest (:thumbup1:)
  11. Same username and logon as the Forums
  12. Bonus: Visible download links to patches and other bug-related minutiae


Additional Thoughts


  • I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
  • I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
  • Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.



(Picture first spotted on Breakpoint)


Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.


My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!

I recently retired from my job as an electronics engineer. Prior to leaving I had been using LabVIEW to create a number of scientific instruments based on data collection and logging. I attended a couple of training courses in Newbury and was getting quite comfortable with the software. Unfortunately I no longer have access to LV and the educational discount option available from the company no longer applies for me.


However just because I have retired does not mean that I do not want to generate more projects using the knowledge gained during employment. My main area of interest is home automation, alt energy monitoring and control etc. I am finding it very frustrating that things I could do quickly and easily in LV have to be achieved using other software, this means yet another learning curve.


I downloaded SignalExpress LE a while back and was hoping that the software may go just a bit beyond data logging but it does not. There is no way to manipulate data in real time so again I have to look for other software.


The full version of LV is priced too high for my application and it occurred to me that there may be an opportunity for NI to provide a stripped down version of LV for consumer use. This version would need to include vesa, basic arrays, basic math, boolean and charting etc. The inclusion of drivers for 1 wire devices would also increase the appeal plus ready made vi's for the usb acquisition hardware. Pricing may be an issue but for non-commercial use it would have to be well below £100


Incidently I was contacted by customer support shortly after downloading SE LE and it was during our conversation he suggested that a post on this site may be appropriate.







When I build a LabVIEW application, I do not include the runtime engine in the installer.  Instead, I have a separate project that builds an installer for all the runtime components my applications need.  That way, my users can perform the runtime installation once and then update the app separately many times.  This keeps my installer sizes small and easy to distribute.

One issue I run into is when I move to a new version of LabVIEW.  I need to make sure all my users update their systems to the new runtime engine before they try to install and run my latest release.  Unfortunately there is no way to enforce this in the installer.  You can check for an installation of the LabVIEW development environment (see image) but that is not very useful.

So, my idea is to add the option to check for the presence of the runtime engine for the version of LabVIEW you are using to build your installer.

Additionally, it would be nice to have a way to check for other required components, such as .NET versions or other NI runtime components or drivers.  This is similar to an idea I posted a while ago here.



installer idea.png

There should be an option to choose which version of LabVIEW want to

build your application, so would only be loading the vi's corresponding to avoid

version compatibility problems.


Further updates NI LabVIEW should create, so each developer would install

 the latest version and any patches that were wanted to use.


If I owned the LabVIEW 2010 and would want to work with  8.6 would install

a patch for this version and not like today having to install the LabVIEW 8.6 whole

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.


There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.


Smiley Happy

I often need to build applications and installers that include VIs or .LLBs that have been built  earlier on...but this is a major pain because as long as LabVIEW recognises the file type it will try to link the VI or VIs in the library to the other VIs in the project, it finds conflicts etc. There are ways to come around it yes, but not very elegant ones.


Basically what I want is for projects to be able to treat VIs and LLB files as non-LabVIEW files. Just like you can include a text file, a JPG picture or other files in your project and installers I want it to be simple to add "completed" LabVIEW files.


One solution could be to have another type of project folder. We have auto-populating folders...perhaps we could have a folder for pre-compiled / to be treated as external sources folder...? In most cases for me LabVIEW could just see that the file does not contain any source code and then treat it as a "dead" file..or at least give you the option to do so (if there is a potential conflict).

Living in the dark ages I do not have web access on my LV development PCs and so have to go to to turn on LV after every update/install. If I am lucky I can sit my LV machine beside my web PC and type in the computer ID code and vice-versa with the resulting authorization code. If I am unlucky bits of paper, pens and walking become involved. Having to authorise on each PC is reasonable but if I need to authorize more than one product e.g. LV and Application Builder (I have the Pro version) then not only do I have to licence 2 things but I have to enter ALL the data twice - a simple 'activate another product' button at the end of the activation pages (with data like pc id and licence number and name etc retained) would make life easier. My appologies if there is one already - but if there is it needs to be more obvious.

The right side of LabVIEW Getting Started window presents links to resources can help the LabVIEW user to be successful in its application development.


With LabVIEW2009 links that update dynamically has been added under Latest from I found very useful to be updated on LabVIEW News directly from the Getting Started window but I would like to see the news published by the local branch.




If the link is localized, I can be updated on new events organized in my Country, on new products release and announcements written in my native language.

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.


At my current work place we use proxy servers as an internet connection. With LabVIEW it makes it difficult not only while the NI software is being installed (to check for updates, connect with server for veryfication etc) but also during typical work it makes troubles with finding examples and drivers from a development enviroment.


I would suggest adding some advenced internet connection options for proxy settings etc.


Another little thing with a company computers is that, even when installing NI software on a D drive it still installs some example software on C:. It makes problem when your IT limited your C drive for absolute minimum, because with huge amount of NI software the amound of "additional" data is getting bigger and bigger.





There have been several ideas proposed to alleviate accidentally savings vis in the wrong version of LabVIEW. While useful, I think the main problem is that LabVIEW doesn't use the information it reads from the file to preserve compatibility. I'd like to propose here that LabVIEW introduce compatibility modes for previous releases in which LabVIEW will break a VI if a feature is introduced that isn't supported by the compatibility version. It will essentially be a built-in, seamless "save for previous" mode. 


By default, LabVIEW will load a VI (hierarchy) in a compatibility mode for whichever version is was saved in. If the user tries to make a change that isn't compatible, LabVIEW will alert the user and the user can tell LabVIEW whether it's ok to save to a newer version that supports the feature.


The level of alerts can be configurable, of course.


Related ideas:

Version-aware LabVIEW launcher

Add header to LabVIEW file to contain the version of LabVIEW

Display VI version in title bar

Version independent Source Code Saves

LabVIEW opens the file in the version of LabVIEW that was most recently opened instead of the version the file was saved in.  Add a header to the file to allow LabVIEW to open the file in the correct version.  This will save a lot of time and lower frustration of accidently saving a file in the newer version.

Our facility runs only one version of labview at a time and that majority of time for installing a new version is spent removing the old version.   A check box on the installer to remove or update the previous version would be a great addition.  In recognizing that several companies must support multiple versions of labview removing the previous version should just be an option, not required. 2nd having the option to select all toolkits and addons to install from the first disk then just a prompt for the other install disks as needed would really speed up the install process as well.

This is not my idea, but I did not see it here and it is a good one so here goes. A lot of people used to deliver chunks of code as DLLs or EXEs but not use them as DLLs or EXEs. Instead they would use them like LLBs and make VI server calls to them. This was possible because when it came right down to it, these DLLs and EXEs were LLBs with extra stuff. This changed after 8.2. No worries because there is the source distribution. Except that the the source distribution is exactly what it sounds like. It is a copy of the source meant to be sent to some other developer. It does not do any of the compile time processing, such as remove conditionally disabled code, that the DLL and EXE builds do. Delivering drivers and other chunks of code as LLBs is a convenient way to distribute patches and so on. But if any of your code has conditional disables, it won't work. The suggestion is to allow the option in the Build menu to remove conditionally disabled code from the source distribution. Here is a thread that discusses the issue.

If LV can create .exe file independent to LV runtime engine, that's will make her more pretty than other programing tools(e.g VC++) 

I remember this in previous (pre-8.2) versions of LabVIEW - not sure why it was removed.  I have a use case to use projects as templates (like when someone wants to write a plugin for a utility I've written, I want to be able to send them a zip containing a project, methods, etc).  The project includes installer settings (so their files go into the right place under my util's plugins folder, but when they build and try to install their plugin, they get an error if another plugin bult using the same template has already been installed.  This is because the "Upgrade Code" (stored in the lvproj file) is the same (it tells Windows that the two products are the same, so subsequent installs are seen as upgrades or replacements, not new installs.


Upgrade Code.gif


My memory tells me that I used to be able to hit a "Generate" button somewhere which would give me build a new code - all I'm asking for is that back (I can add a step in my work instruction to hit that button before you build).


I don't currently have a workaround for this (other than having engineers manually edit the lvproj file) - if anyone has a better idea, I'd love to hear it for the interim!

Does this idea need any more explanation? If someone swipes the box out of a mail slot at work and installs it at home, that becomes the "at home" installation. 


I realize Ideas with pictures do better, so here's a Golden Retriever puppy...



Message Edited by Broken Arrow on 06-11-2010 07:40 AM
Message Edited by Laura F. on 06-07-2010 02:03 PM

When you use "Labview Web server", you cannot access your Labview front panels using IE from a PC with no Labview Runtime.


To make it work you have to install a Labview runtime, or deploy manually some dll's ...


So, it would be nice to create a "light Labview Web client installer" in order to only install the minimum required.