 |
|
||||||||||||
With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number. For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later. Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions. However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:
- Changing VI connector panes
- Renaming or moving VIs on disk
- Adding VIs to a library
If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.
LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs. Consider the case where I make the following changes to a VI from my toolkit:
|
|
Version 1.0 |
Version 2.0 |
|
VI Path
|
<userlib>\mytoolkit\CompRes.vi |
<vilib>\mytoolkit\Compute Result.vi |
|
Owning Library
|
none |
Mytoolkit.lvlib |
|
Connector Pane |
 |
 |
I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI. This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.
The list of available LabVIEW modules and device drivers is very long. Their names tend to be long too, which is compounded by the many levels of nesting. Modern screens are large.
Given all that, why are we selecting software components by scrolling around a tiny window which can't be expanded?
(Note: most of the trees above aren't exen opened yet!)
Proposal: Make the window bigger (vertically and horizontally), or resizeable, or both.
Thanks for listening!
Currently, if you want to install LabVIEW 64bit, you need to download it from ni.com.
My idea is to put it on the LabVIEW Platform DVDs.
It should be there. I am paying to get my software on a DVD. Please include it on my DVD.
The only reason I can think of for NOT putting it on the DVD, is that NI is worried that inexperienced users will install the 64 bit version (afterall, doesn't 64 sound bigger and better than 32! 
), and NI will get tons of technical support phone-calls from the resulting confusion.
Create a single Windows Restore point during installati
Nickerbocker
on
Currently if you commit to installing the full NI Developer's suite and something goes wrong with the installation you can forget about using the Windows Restore feature because the installation process creates a new Restore point about every 1-3 minutes. That is unnecessary and problematic for a number of very obvious reasons.
When you run the LabVIEW Platform DVD, the default setting is that LabVIEW gets installed and nothing else. You can then go pick and choose what modules and toolkits to install. I like this default because I usually only want to install LabVIEW and a few other modules and toolkits. It is faster for me to select the few modules that I want to install rather than unchecking all of the modules I don't want to install.
When you run the Device Drivers DVD, it tries to guess what drivers you want installed based on the software you already have installed. However, it usually wants to install more drivers than I want it to install. It is a hassle to go through the driver list and unclick the drivers I don't want to install because most of them have dependencies that you have to unclick first.
Idea: Their should be a button on the Device Drivers installation screen to unselect all of the drivers (see image below). I don't think the Device Drivers DVD default should be the same as the Platform DVD; a lot of new users won't know what drivers they need and installing all of the recommended drivers is a safe bet. However, many users do know what drivers they want and it saves time and hard drive space to only install the necessary drivers. Adding an "uncheck all" button would make this process faster and less frustrating.
Add an "Uncheck All" button!
At some point the LabVIEW installer stopped asking who I was and what company I work for during the installation process. Instead, the LabVIEW installer assumes that the "Registered Owner" and "Registered Company" of the Windows installation is what should be used. I'd like it if,
- The NI installer stops making this assumption and prompts me for this information.
- It was a changeable option in LabVIEW (because changing every registry key doesn't seem to do anything)
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.
Currently in LabVIEW if you build an installer you end up with a hierarchy of files that look like this:
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:
This can be as easy as a checkbox in the current installer Advanced page:
Add an option to Applicatio
RDR
on
With Application Builder installers there is no way to flag a file as a 'shared' component in the build specification. This feature is used in MSI installation when files are shared or common among multiple product installers; for example, the files located in \National Instruments\Shared are common dependencies for NI products or in LabVIEW-built EXEs this could be a shared dependency between two applications, like a DLL. Currently, if two product installers built in Application Builder install the same file, when either of these products is later removed the shared dependency goes with it and the second product is broken!
Some good news is you can use MSI editors like InstallShield to edit the MSI after creating it with Application Builder in order to enable a tag/setting for your shared files:
There are also open source MSI editors available, like Inst Edit, with similar options for tagging files as shared components.
What can be done in Application Builder?
Could an option be added to 'Source File Settings' to tag files as 'Shared' so a third-party MSI editor is no longer necessary?
One example is shown below from the Device Driver Installation dialog but there a many similar cases. It is very difficult to obtain a decent overview having such a small window for the tree display.
I suggest as a general style guide to always enable the resize option in a dialog box whenever the layout requires a scroll box.
I have a hard time to see what could be reasons not to do so.
Have a LabVIEW Idea?- 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!
- 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. - Watch as the community gives your idea kudos and adds their input.
- As NI R&D considers the idea, they will change the idea status.
- Give kudos to other ideas that you would like to see in a future version of LabVIEW!
|
||
|
||
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. |  E-Mail this Page
|
||
|
||