LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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

Currently in LabVIEW if you build an installer you end up with a hierarchy of files that look like this:

 

singlefile1.png

 

If you want to distribute this installer via the web, you need to use a third party program to zip it up, or create a self-extracting zip file.  Since LabVIEW can already create zip files with no problem, I propose the ability for LabVIEW to create a single file installer that can easily be distributed, like this:

 

singlefile2.png

 

This can be as easy as a checkbox in the current installer Advanced page:

 

singlefile3.png

The default LabVIEW environment option should not show terminals as an icon. 

 

IconTerminals.png

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

 

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon).  What I'd like to see is a solution that treats 3rd party installers as first class citizens.  I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.

 

2-3-2010 1-35-27 PM.png

 

This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.

 

2-3-2010 1-41-08 PM.png

 

When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run.  This is a pretty simple scheme that would really simplify the process for end users.

 

I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas.  I'd love to hear your comments.

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

 

  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

When the Developer Suite DVD binder arrives, the first thing I do is find a black Sharpie, cross out the name (e.g. 2010) on the binder label, and write the version of the software it contains (e.g. 2009 SP1).

 

Rarely if ever do I care which year the DVD binder shipped to me -- all I care about is the version of the software (the most important being LabVIEW) it contains.

 

Now that LabVIEW and most other NI software products are on an annual release cycle and named according to the year and service pack, I would love it if the Dev Suite binders were named the same way.

Currently LabVIEW only has support for Mandriva, RedHat and SUSE Linux.  What's even worse, only 32-bit versions of those are supported.  Today, 64-bit linux installations are on huge raise, and Ubuntu is getting more and more popular.  LabVIEW Linux support should be expanded to include Ubuntu, and 64-bit versions are needed.

 

cheers,

Pekko

 

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

 

This is not directly related to LabVIEW but I haven't found any other thread which seems like a better fit. I'm posting it on the Idea Exchange since this is the best place for other customers to potentially agree with me.

 

NI drivers/software are quite often large, and above 1 GB is not uncommon and sometimes above 3 GB. Having everything in a single file is in my opinion a good thing because I don't have to look for multiple driver parts and download packages, but the file size must be matched by the download speed. Waiting three-four hours or more to download a single driver is not a fun thing to do and quite often you need more than one driver.

 

Sometimes the speed is okay, but as a general rule I would say it's slow. I'm located in Sweden and of course this issue is dependent on a lot of links between where I am located and the server where NI host the files.

But, download speeds of 200-300 KByte/s from NI are not uncommon but I can run speedtests on for example http://www.speedtest.net/ and get download speeds at 50Mbps using American servers.

 

I don't know how NI host the files, if it's internal servers or something else but it would be nice if NI looked into the possibility of somehow making this faster.

 

I downloaded LabVIEW from ni.com and installed it.  Here's the process:

 

  1) Download a small downloader using my web browser.
  2) Run the downloader, which then downloads a self-extracter
  3) Run the self-extracter, which extracts the installer
  4) Run the installer

 

I'm thinking that this process can be improved a little.

I propose that NI award anyone who posts an idea (especially this one) which is eventually accepted receive a free copy of the LabVIEW Developer Suite as an award for their creativity.

 

Should help find duplicates!

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

A lot of engineers prefer Linux over Windows and would use it on there test machines if at all possible. Instead of attempting to support a wide variety of flavors, wouldn't it be better if NI would derive it's own flavor from an existing distribution and committed to having full support for all NI software and hardware for this new flavor. This would give Linux aficionados the OS they crave and NI the power to control the direction of the OS such that it makes hardware and software compatibility easier.

NI Linux.jpg

I think it is useful if the installer automatically 'Force Re-install' if the same software has been already installed with the computer. This will omit the procedure to kick-start force re-installation via command prompt, some users may not be familiar with.

 

 

force reinstallation.png

For example:

1) install based on a license: this would install only the software related to a license;

2) reinstall/update based on license OR based on what's already installed.

 

For every new update of LabView I need to select the installation  of the toolkits I want, why not make it faster?

Trying to toggle back and forth between the instructions and the code for the online CLD exam was both distracting and difficult since most hot keys didn't work. Placing the instructions or goals in the block diagram would allow easier reference for those taking the exam. 

The latest release of the Vision toolkit (Vision 2012 SP1) provides some much needed improvements to the AVI functions.

 

But at the same time, it introduced a new issue:

 

"The Quality input in the IMAQ AVI2 Create VI is only implemented for Windows
codecs. The Quality input is not implemented for codecs installed with the
Vision Development Module."

 

This is very unfortunate, because it worked fine in the previous release (see here)!  This means you may want to reconsider upgrading to SP1!

 

My idea:  Fix this!  Re-allow the use of the quality parameter in the AVI functions so we can better compress our video!

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:

 

22863iA75EB0F1A77A1685

 

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

the selected installation dir from the user.

 

6e3fb8943920.png
Message Edited by Laura F. on 06-07-2010 02:03 PM