I suggest that NI clearly mark those functions in IMAQ that require a run-time license. Perhaps color their icons pink or some noticeable color. There is a lot of misinformation in NI technical support regarding this issue. I wasted a lot of time developing an IMAQ program and found out later that it required a run-time license that my client did not want to buy. So, I had to rework the code to eliminate those functions that require a run-time license.
Installer needs option to conditionally install files. In some installs, like a new install, the installer should install a file but that same file should not be overwriten on an update. For example, a database file that is updated by the user will be overwriten by the installer. The options required are:
Install file if not present.
Install file or not install if file is modified.
InstallShield should be consulted for the various options required.
Whenever I install a new version of LabVIEW, I have to wade through the LabVIEW options to change all of the UI settings to what I like. To make the upgrade process easier, I would like to see a dialog that:
appears on the first launch of the new LabVIEW version
can be easily skipped by users who would rather configure things manually
allows users to choose common settings (aimed at users without another version of LabVIEW on the machine)
provides a user friendly way to import settings from an older LabVIEW version (aimed at users who are upgrading LabVIEW)
This would make the process of upgrading much easier, especially for users who have very particular preferences. Some options that could be addressed in the wizard are:
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.
Provide an option to display a QR (2-D) code in the product activation dialog. The QR code should contain a web address that would return the activation codes for all selected products. For those of us stuck out in a lab or factory with only our smart phones this would provide a slick, foolproof way to enter all of the data needed. It would save us from either making a round trip back to civilization (with a pad full of info) or getting carpal-tunnel trying to type all that stuff in on a little soft keyboard (multiple times for multiple activations = hand cramp). We would still have to type the resulting activation codes into the LabVIEW activation screen but that's a lot easier than all the rest.
1) Provide a http link as a QR code
2) Have the target web page auto-generate the activation codes and display them (preferably in a mobile browser friendly format)
3) As an alternative, let the user upload a picture with the QR code to the NI activation web site for the same result (works for anyone with a camera not just smartphone users -- this would also let you show off IMAQ.)
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.
Consider expanding programmatic modification of the Build Process. There is already an Idea here to allow the Pre-Build Action to set the Version Specification before the Build Process (it happens during the Build process, after the before-the-change Version Specification has been cached and used in the Build). However, other Specifications in the Build Spec would be very useful to be able to specify in a (true) Pre-Build Action.
Target Filename (low priority)
Destination Directory (I like to put Builds in Public Documents, but the Public Document folder can "move", though LabVIEW's Get System Directory can find it, so I could "pre-build" a path specific to the given PC)
Build Specification Description (allows the user to include version-specific or Build-Time text)
Version Information (in addition to Version Number, before being used, the other Fields might be useful).
I've noticed references on the Web to automated Builds, and know there are Build VIs that will do a Build. I also know there are a set of "barely-documented" APIs that some have used for this purpose, but I don't know (other than the Set Version Specification, which doesn't work as I expected in a Pre-Build Action) of others. I don't especially want to poke around inside the Project's XML file -- can we consider adding some other "Pre-Build" Set functions? Could (for example) some of these "Build Properties" be set with a Property Node? Maybe this functionality is already there and I've not found it ...
During LabVIEW installation if it detects a previous version of LabVIEW has been installed it should present the user with the option (or have a flag when running the installation to allow this to be done silently) to import all VIs which are not installed by default that are present in the following folders:
vi.lib (VI Package Manager installs packages to this location by default)
Upon importing the VIs to the new LabVIEW installation it should also mass compile them to the new LabVIEW version so the user is not faced with having to save loads of VI dependencies each time the user opens a VI which uses them.
This would make the getting started with the new version of LabVIEW a lot more seamless when just upgrading from a previous version.
Currently I use LabView through a Windows VirtualBox on a Linux Mint machine. I was told by a customer support employee that I should bring this idea to this forum. I chose this method because of the limited support for Linux even with the supported distro discs. I encourage NI to expand their Linux-compatible software to have the full capabilities that the Windows and Mac versions do for the distros that are currently out, and to expand the number of distros supported. Linux Mint is one of the most widely used flavors, and yet there is no support from NI.
This tool has a lot of potential for end-user use if it is incorporated into the app builder API and suite. Batch installers can be used for much more than just installing selected sets of NI software (Which this tool is obviously designed specifically to do). It could be used for creating installers of multiple, cross-project user installers comprising a complete system. To do this though, the current batch installer builder needs to be made more generic to be of use.
Add configuration options to control or disable license dialogs when non-NI provided installers are added
Add configuration options to control or disable the user/company license dialogs when non-NI provided installers are added
Add configuration options to control or disable the check for NI updates dialogs when non-NI provided installers are added
Add batch installer version properties to allow end users to create system versions
Add support for 3rd party installer inclusion (Dup from another idea, but I had to repeat it here)
Including this in the app builder would be even better since that should allow project based configuration and control of the batch configurations and potentially even programmatic control.
Activating an NI Software licence on a computer without internet access works fine but take too long and is user mistake prone because we need to type long strings of characters.
Now we have to :
- go on PC/tablet/smartphone that has internet access
- go to ni.com/activate,
- select the product type,
- select the product version (be carefull to select the version we installed, not the version we recieved*),
- type the serial number,
- type the computer ID,
- then we obtain the activation code that we have to type on the computer.
Bold steps are human-error prone.
If you've done that once from a smartphone, you know how painfull and error prone this process is.
This process should be shorter and much less error prone, something like :
- the PC without internet show a QR-code that contains product type, version needed and computer ID,
- launch the "NI Soft Activation" app on your smartphone
- scan the QR-code
- type the activation code given by the app onto the computer.
Only one human-error prone step in that process.
* : when you purchase a runtime licence from NI you automatically recieve a serial number that can activate the most recent version of the product, but you can use it to activate older versions of the product as well. Say youwant to activate Vision Development Module RTE 2010 but you recieved a serial number valid for up to version 2012, when you go to the ni.com/activate you have to be carefull to select the correct product version (2010 in this case), one more possible human mistake.
The Vision Utilities are currently installed with either the Vision Acquisition Software, Vision Development Module, or NI-IMAQ. Since NI-IMAQ is a free download that anyone can install and deploy without any additional licensing it makes sense to include it in the LabVIEW installer.
The Vision Utilities provide superior image management , are owned by NI-Vision (meaning they are actively developed), and best of all are free. Including the Vision Utilities in the LabVIEW installation will expand their exposure and use. Below you'll see the first three results returned when one seraches for IMAQ on ni.com and sorts by examples. In addition to the examples shown below you can find a list of all the VIs currently included for free in NI-IMAQ here.
Just found out MathScript Module does not have a 64-bit version yet. I don't know if NI has any timetable to release its 64bit version?
Why do I need a 64bit version? Mainly the memory issue. I have a Matlab code which requires a massive memory allocation. Now I am trying to use the .m code in LabVIEW, but encountered a 'Not Enough Memory' warning message. I think a 64bit version shuold fix this issue, correct?
Besides, 64bit is the future anyway. So in case MathScript Module 64 bit is not even being considered by NI, I would like to suggest it here.