LabVIEW Idea Exchange

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

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. http://forums.ni.com/t5/LabVIEW/conditional-disable-no-longer-works/m-p/1109759

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
6e3fb8943920.png
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.

 

Manu.

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.

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.

There is a logical glitch in the App.Version property; If you read App.Name you get the name of the built application...but if you read App.Version it's not the version of the application - it's the version of the RTE.

 

I use the application version in splash screens etc. - however today I have to manually write this multiple places because I cannot read the version number I used when building the application.

 

 

 

I would like to see future versions install without changing anything in already installed LabVIEW versions. No updates to toolkits, add-ons,  or anything else. After the install, the previous version(s) should work exactly as they did before the new install without any changes. I would also like to be able to install older versions as if there was no newer versions were installed.
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

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

 

It has come up in discusssions that NI does not really cater to hobbyists. A cheap and functional version of LabVIEW is limited to the student edition, which is restricted to a small subset of potential users.

 

 From the  FAQ:


"The LabVIEW Student Edition is available to students, faculty, and staff for personal educational use only. It is not intended for research or institutional use."

 

As a suggested first step, I suggest to remove the academia restriction and mold it into a new product:

 

--- LabVIEW personal edition ---

 

Licensed as follows:

"The LabVIEW Personal Edition is for personal use only. It is not intended for commercial, research or institutional use."

 

 It would be available to anyone for noncommercial home use.

 

LabVIEW currently has the home use exemption that allows installing a copy at home. Unfortunately, if you lose your job, you not only lose your health insurance, but you also lose access to LabVIEW, thus hampering any self paced LabVIEW tinkering that possibly would improve future job prospects. I am sure many retired LabVIEW engineers would love some recreational LabVIEW use. They could be a great asset, because they will have more time helping out in the community and forums. They could even give guest presentations at user group meetings, for example.

 

The LabVIEW personal edition should include all modules of interest to the hobbyist, including application builder, embedded, FPGA, and robotics.  We should be able to distribute built applications as freeware. Support would be limited to community support.

 

Installing LabVIEW on every single private home computer in the world would cost NI exactly nothing (except for some sales of the current student edition which is about the price of a textbook, some internet bandwidth, and loss of the zero to two (?) multi-millionaires who actually bought the NI developer suite for themselves. ;)). 99.9% of users would never touch it, but that 0.1% could come up with great new application areas and would help spread the word on how great LabVIEW really is. Soon 0.2% would use it. 🙂

 

It should follow the "customer class limited" Freemium model, (as defined by Chris Anderson), i.e. limited to personal home use in this case.

 

The running applications should be clearly identified to prevent commercial use. The splash screen and "about" screen should prominently display the words LabVIEW and National Instruments and could even be used for NI advertising and product placements, for example.

 

 

If I'm the first to post this Idea then I'll be shocked.

The Idea is simple. We all love programming in LabVIEW, and I'm sure that we've all at one time or another had a colleague, friend or family member ask if we know how to do something on the PC. The immediate thought is I don't know where to get the software to do that, but I could write a simple LabVIEW app  in a few hours that does the job.

E.G hunt through someone's PC and move all of the jpg files over a certain size to a specific location so they can easily find their holiday snaps.

 

You can't create this simple function for them, because if you do, and build an exe, they still need the Runtime engine.

 

Surely for REALLY simple stuff (File IO, basic comms stuff in the Base LabVIEW edition ...) - not DAQ or anything like that it is possible to create an EXE that INCLUDES the runtime components that it needs and is stand alone.

 

This would open up LabVIEW for the use of making quick gadget like apps for the office as well as test and measurement.

 

I can't se how this could be a bad thing.

Add an  option in the installer build to run cleanup-programs during uninstall.

 

On the advanced tab in the Installer build there is an option called: "Run executable at end of installation", but there is no such option for the deinstallation.

 

We use the existing option to run a batch file that installs and starts the application as a service. If the user decides to uninstall the application we would like to run another batch file to stop and deinstall  the service - but there is no option to run an executable during deinstallation.

The list of available destinations when you build an installer includes Common App Data Folder, but not Personal App Data. So instead of being able to just install an initial set of settings during installation we always need to hard-code the creation of those files.

 

It would be conventient if PersonalAppData was available as a destination as well - or even better; that the options included *all* the OS's standard folder references. Or that you could at least create new references to such system folders.

One thing prevent our company to upgrade to newer labview is that the run-time engine gets too big. Even I really like the features in later version, I still have to save the files back to 7.1 then to 7.0 to build application installer. Under 7.0, the run-time engine is very small, and the installer is less than 10MB and I can easily email the program to customers. In version 8.0, the run-time engine is 65MB and now the latest version is well above 100MB.

 

What I would like to see is that application builder get smart, only pick what is needed and build slim app.