Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
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.
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.
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:
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 ...
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.
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.
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.
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.
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.
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)
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.
To statically use a packed library as a dependency, you need to add the library to the LabVIEW project. After that's done, all the callers link to the packed library. If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.
But what happens if you're a packed library user and developer of the same library. You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.
If you're a user and developer, it makes sense (to me) to maintain two separate projects. One manages the packed library resource, one manages the application.
What if there were a way to revert the packed library to the LabVIEW library from the same project? You could use the spiral development model and simply switch between the two types of libraries during development. You could also (and this IMHO is the most important part) incrementally deploy and test the project. If you're strictly a packed library developer, hopefully you're incrementally testing anyway.
My final pain point with the packed library is with respect to upgrading the application. Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade. If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp. Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself. I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).
This leads me to a best-practice for lvlibp: always use them as dynamic dependencies. That way, you can maintain and develop the packed library in the same project that uses the packed library. You'll simply reference the resources differently.
Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.