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.
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.
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.
"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.
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.
We need the ability to manage multiple volume licenses from a single VLM instance. We have several groups from different cost centers that use LV; however, currently all the license administration falls on me. The only solutions available at this time are:
Merge all the licensing needs from each group into a single license. This is a nightmare for me. For one, our internal accounting system isn't set up to easily transfer funds between cost centers, so getting the money to pay for the license has been difficult and usually leads to payment delays. Second, it's very difficult to respond to changing license requirements of an individual group when everything is lumped into a single license file. If a single group wants to discontinue their subscription, rather than just letting the subscription expire (which would cancel the subscription for all groups) they have to pay a fee to "break out" their licenses from the volume license. If a group wants to add products to their license, all requests get funnelled through me. This might be good for NI, but it's a royal PITA for me. (License administration is something I do in my "spare" time.) Third, it's inconvenient having to track how many licenses of each type each group has purchased and cross check that against how many licenses they are using.
Maintain separate computers for each VLA. From an ease-of-use perspective this is almost as bad as option 1. From a practical perspective this is worse than option 1. It's silly to have several different computers sitting around doing nothing other than running a license server. Furthermore, it's harder to loan an available license from one group to another group (which does sometimes happen) as the user has to redirect to a new license server.
Neither of these solutions work very well. I don't mind the license administration part of the job. Creating installers, changing permissions, and stuff like that doesn't really take that much time. What is killing me is the account administration part of the job. The single license model forces me to be an account administrator for several independent groups, and the corporate culture and infrastructure here don't support that model very well at all. What I would like to be able to do is have each group be responsible for purchasing and maintaining their own volume license agreements. When they get the license file they can send it to me and I'll install it in the VLM.
I envision each VLA having it's own root node in the tree diagram. Instead of a single "Volume Licenses" node, there would be one for "Group A Licenses," another for "Group B Licenses," etc. (I have to be able to rename or annotate the root node for each VLA.) The Users and Computers nodes still contain the users and computers from all the groups, but maybe those nodes have virtual directories I can use to organize them.
This is only a wish that NI could provide a Utility that converts a VI or Dir to Up or Down.
I had a project that was done in LabVIEW 5 (done many years ago by someone else); I couldn’t open in LabVIEW 8.6. I needed to do stage upgrade LabVIEW 7 and follow up with LabVIEW 8.6 and so on.
I understand there are cases that you can not simply down convert, because newer function may not be available in older version. In this case it OK, give user an option for force the convert and worse case the down convert VI is broken. Let the programmer fix it!
The utility should have a Status Report for convention.
The title says it all - I'd like to have the option to inherit my configuration settings from the previous LabVIEW installation (or from a specified path). Currently I have to do this manually by copying the ini file from the previous version, but I'm never sure whether there will be compatibility issues with the new version of LabVIEW or if there are obsolete settings. The installer should check for compatibility/obsolescence issues as it creates the new ini file.
Alternatively / additionally, I'd like to be able to specify where LabVIEW loads the LabVIEW.ini file from (which could be located on a network or USB disk).
Microsoft introduced a number of restrictions in Vista that makes it more difficult to save program settings and temporary files.
Applications can no longer write to the Program Files directory, but even worse; the common application data directories, like ProgramData and Users\Default are by default only accessible for writes by administrators and the first user that did the write. Sessions by other users only have read access. The same goes for registry access; the computer keys can not be written by everyone.
As long as it is OK to not share settings between user's you have one good option left; the user's appdata folder. If you do need to share data though - you need to set the access right of the folders you create in the "common" directories. This can currently be achieved e.g. by using a tool like SetACL, however as it has been made a required action now, it should be included in the installer - AND preferably also as VIs on the file and registry (for registry access) palettes.
LabVIEW 2009 introduced one of the tools required to handle the UAC changes - a VI to get the paths of system folders. It should also have a tool to grant access to some of those paths...
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.
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.
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.
When installing a new version of LabVIEW, I always find myself resetting all of the options I previously changed from the default settings in the Tools -> Options menu. This means I have to spend my time remembering what options I changed and where in the Options menu I need to change them. It would be nice if a newer installation of LabVIEW looked at the older version's Options settings and then applied those settings to the new installation.
The same idea applies to how I configure the palettes on the block diagram. It would be nice if newer installations looked at how I configure my palettes and then set them up the same way.
With these changes transitioning to a newer version of LabVIEW might be even more seamless for users that change their settings from the default settings.