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:
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:
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.
According to the increasing number of questions about this communication protocol, it would be time to rewrite the MODBUS library. I also suggest to add it to the NI device drivers installer.
This could be the place to list the expected modifications. Some comments and bugs are already listed in above linked page.
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!
After much frustration searching the Labview help and NI website I finally came across the reason why my project kept coming up with vi file conflicts and/or using the incorrect version of a vi. Apparently when searching for a vi, if there is a windows shortcut (.lnk) in the search path, it follows it! Now this is a very powerful feature but a dangerous one too. Apparently this has been a feature of Labview all the way back to version 1.0 This fact is not mentioned anywhere in the Labview help but I did finally find this article: http://digital.ni.com/public.nsf/allkb/B43C655BA37
In my case I have lots of example code on my PC. I often put shortcuts to similar code in the same folder with VIs and project as a quick way to reference alternate methods of accomplishing similar tasks. No problem, I'll just turn off this feature in the VI Search Path page of the Options dialog, right? Much to my surprise there is no way to turn this off.
Suggestion: Please add an option to disable this feature in the VI Search Path page of the Options dialog. Even if this option is dismissed and not implemented, please at least add this information to the Labview help, perhaps in the Paths Page (Options Dialog Box) if not in several other places in the help. It would certainly have same me hours of frustration and lost productivity.
When I build a web service in LabVIEW, there is no version number updated for each build. If I then install that web service on my target, I have no way of determining what build has been installed.
I have solved this by creating some scripting VIs that update a VI control's default value when the build is run. This VI is available via my web service so I can ask it what version it is.
I think everything that can be built from the project should have a version attached to it and that version should be accessble and reportable. Also, it should be possible to auto-increment it.
Once upon a time one could distribute code that was reasonable in size. Now it seems all the runtimes are giga byte size.
It takes far to long to send someone a distribution with all the runtimes. Try uploading 1.7Gig of files...
Can this be reduced at all?
The FPGA compiler needs version 10.4, 11.5, 13.4. This directory is 19.5 Gig! If this directory is included in the backup, it too will take up a great deal of storage resources.
Can this be streamlined?
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.
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!
When I run the installer for my application, I want to display to the user the version of the exe that will be installed. Since this exe already exists, I should be able to embed a tag in the installer dialog text as a placeholder for this version. Something like:
This installer will install version %my_exe_version% on your machine.
When the installer is built, the tags are replaced with the actual versions.
This should also work for all components being installed (DLLs, web services, etc)
As a bonus, it would be nice to have access to user defined tags in the build spec that can be embedded into installer dialogs. Perhaps allowing a prerun VI to populate these so we can invent new ways of adding infomation in the future. (like accessing user information from the OS and using that to customize the dialogs)
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,
Is it just me, or does the "progress bar" (that actually doesn't show a % progress -- it's a mystery) create optical illusions (and especially when it's animated)? It kind of makes me dizzy to look at.
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:
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?
For a lot of reasons, I have to work with several LabVIEW versions.
My biggest fear is to save something in a later version : projects are quite big, and a save for previous version is hard when using terce parts (such as OpenG, JKI, etc.)
My whish would be to have a warning message when I save a vi in a new version, such as :
"You are saving a 8.2 file in 11.0 : do you want to continue ?"
Have a nice day !
When you create an Installer you need to select what is the other build spec that will be used to be installed.
Some time in the resulting files of an EXE build spec we got files that we don't need to be included in the installer.
So I propose to be able to select only the file that need to be installed, not the entire EXE build spec result.
Currently the EXE build spec result files are grayed out and we can only select the entire EXE build spec result files to be included in the installer.
All the other Build Specification has already this function available. Why not the Installer and the ZIP File.
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.