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 search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".
I know there are others out there like me, I HATE upgrading Labview. All the time required to update your custom configuration takes weeks. Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.
Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software. For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.
My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV. Making the upgrade process easier with a single tool.
Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade. If it was more seamless to upgrade, I'd probably upgrade every release!
Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.
Perhaps NI should accumulate all of these requests to Upgrade and total them as one. Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.
Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.
Propose to have RAD utility to include a "Snapshot/Clone" function that snap the image "exactly as is" the state of the cRIO/PAC at that image creation instance; that would include the entire drive structure, configurations, bit files, network settings, etc. Restoring from such type of image onto the cRIO will, without fail, guarantees its functionality (at least back to the state the image is created).
This come after the 2nd time of suspected corruption, when I deployed with error in LV causing irreversible/permanent impairment to my deployed RT application. First time being without a backup, that led me to reformat, reinstall and redeploy for one mistake in deployment. Second time being with a backup, apparently incomplete image using the RAD16 (http://www.ni.com/example/30986/en/), upon deployment failure and image restoration, the damage has not been reversed.
Hopefully to see this option developed soon, as the conventionally advised method of reformatting, reinstalling and redeploying cRIO, is not really practical.
I faced issues while creating an installer with a size of 2GB+. Unfortunately I had to upload the installer to a shared site that didn't accept files > 400MB. The want for a separate installer and process thereof delayed my delivery.
I remember from other software(s) having distro creation capabilities in size of lets say a standard CD size of 650MB, etc.
Wouldn't it help many if the app builder allowed splitting the installer in a defined packet size?
Please provide a setting to exclude unspecified folders.
I started a Mass Compile on one folder. Whoa, it did more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I was surprised that I gave it one folder to recompile and it saved called Vis even if they were in other folders above and outside of the one I had specified. I didn’t think to back those up.
NI's code should be excluded! Many VIs are installed as part of LabVIEW in the C:\Program Files (x86)\National Instruments\LabVIEW folder. These should NEVER be modified outside of installs/upgrades. I started a Mass Compile and, whoa, it did much more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I didn’t think to back that up. Now I fear my LabVIEW installation is dirty. NI SR#7722650 says "It does go outside of the specific folder if the VIs in the specific folder depend on another VI outside of the folder. When it goes outside, it is just opening the VI and resaving it in the current version of LabVIEW. Because your VIs depend on some VIs in the ... vi.lib it went and resaved them. But, they are already in LabVIEW 2015 SP1, so it will not change anything in them. It does this to ensure the VI is looking at the current version of LabVIEW and not an older version." If that is true, why would installation of a version of LabVIEW install VIs of older versions? Make sure all vi.lib VIs are already compiled for that version.
Mass Compile changes files that do not have a LabVIEW code extension such as ".ctl" and ".vi"! Why is it trying to load, check, and save files with extensions such as ".bak" and “.err”? The following example shows files that a prior mass compile found problems with and I renamed them and removed them from source code control.
### Bad VI: "EditString.ctl.err" Path="C:\cvs\r8000\labview\app\editor\controls\EditString.ctl.err"
### Bad VI: "MCNavigate_old.vi.err" Path="C:\cvs\r8000\labview\app\remote_control\MCNavigate_old.vi.err"
Yes, this is a corner case, but it has bitten more than once. There's no way to deactivate then reactivate third-party plugin licenses for off-line (No internet) LabView development machines. These machines need upgrading and they fail just as often as internet connected machines, yet third party plug-ins are often left in limbo when the computer ID's change.
It would be nice, if during installation of LabVIEW, installer will configure Firewall as needed for LabVIEW. For example, Network Streams - is standard LabVIEW feature, but to use it, one should manually configure Firewall (as described in this KB article). I'm sure, that there are other cases when similar should be done.
Of course, then exe anyway should be added to Firewall exclusions list, but at least one could use and test Network Streams out of the box, without googling out why it does not work...
This feature could be optional during LabVIEW installation, but if it is possible to automate something - then better to have it automated, then refer to some manuals and KB articles...
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.
Installers should show the public version of dependencies instead of internal versions.
This is a specific example, but I presume this behavior is more widespread: An Add-On that has a dependency on LabVIEW NXG doesn’t list the (public) version of LabVIEW NXG upon which it depends.
The OpenG Library v126.96.36.199 depends on LabVIEW NXG v1.0. But the installer indicates the version of LabVIEW NXG to be installed is v 188.8.131.52152-0+f0. To someone not familiar with the internal version numbering for LabVIEW NXG, it’s not obvious that this refers to LabVIEW NXG 1.0. This may lead someone to install an undesired version of NXG.
(I had NXG 2.0 already installed, and I assumed, incorrectly, that the version of NXG that the OpenG dependency referred to would also be NXG 2.0.)
By changing some NIPM settings (e.g., enable the "Show full version numbers and infrastructure packages" option), one can logically (but not definitively) deduce the public version that the internal version is referring to:
I am struggling (yet again) with LabVIEW installation problems that appear to involve LabVIEW 2017 (and possibly LabVIEW 2016 f5 patches). After having systems with multiple (sometimes only 2) LabVIEW Versions installed "go south" (typically by having MAX stop working and Block Diagrams with DAQmx code fail to load), I've tried to "Remove All" NI software, only to discover that "bits and pieces" still remain, both on Disk and (especially) scattered throughout the Registry.
I've been working with NI Support for 2-3 weeks trying to "recover" from a LabVIEW corruption probably caused by installing the 2016 f5 patch. We finally decided to do the "Uninstall/Reinstall" route. Although I got 2012 SP1 installed, 2014 SP1 failed (could not install NI Network Discovery 14.0, "Verify you have sufficient privileges to install Services").
My concern is that, short of reformatting my hard drive and reinstalling Windows (which I was forced to do on two of my PCs), there appears to be no way to fully uninstall all NI Software. I would like to propose that NI develop an "Eraser" utility (like Eraser for Microsoft Office) that searches out all files that NI puts on the C: drive (not in User Space) during installation and all Registry entries that it scatters throughout the Registry, allowing the PC to be "rolled back" to a "pre-NI" state. Such a tool might want to be restricted to Full or Professional licenses, or maybe provided on an "As Needed" basis by the NI Support Team, but I really don't want to have to rebuild yet a third PC ...
NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:
However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:
This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.
During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect Channel_.vi" and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.
While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.
The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:
A LabVIEW application installer generated from App Builder creates multiple folders and files in the folders. It is desirable to have a single file installer so that customers see only 1 file to install.
To generate a VI or set of VIs with a general driver to get low-end FPGA boards to work with LabView FPGA. Parameters will only come from the users to make this dynamic, this would be the total count of I/Os FPGA type, location of I/O items (eg. buttons) in the FPGA board, etc. It would be a bit of work, but also would pay off at the end. Doing such is no more than an extension of LabView if done well, let's say written in an xml file plus it would be a very powerful tool for researchers, and would generate more sales to use LabView FPGA for more researchers, university students, and engineers who want to test a few things without full initial commitment to NI tools.
If someone would have asked if there was a setting to run a VI after an installer was build I would have said yes, until today when I realized I needed it and couldn't find it. When building an EXE there is a Pre/Post Build Actions section where you can specify a VI to be ran before the build or after it. But this appears to be limited to building EXEs and not installers. There are several limitations to the NI building process, and I'd like to improve them by having functions get ran after a build of an installer is complete.
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.
Unbelievably NI has introduced a bug into LV 2016 whereas the "Open/Create/Replace File" function does not display the input prompt to the user. In fact no File I/O functions will display the inputed prompt. Worse yet there are no prompts for finding or opening files within LabView itself. Try opening a vi, there is no prompt whatsoever. In previous versions of LabView there is a prompt telling the user what to do. e.g. "Select File to Open"
This is very bothersome when you open a vi that cannot find a called vi. Prior to 2016 there would be a prompt telling the user what vi it is looking for. Now you are left to guess what vi Labview cannot find.
This is a huge problem for me as I prompt the user to find files and folders in a great deal of my code. If I were to upgrade to 2016 I would have to go through 100's of vi's and add dialogs telling the user what to do prior to calling any File I/O functions.
The most disturbing aspect of this issue is that NI did not fix this bug prior to releasing 2017. It is beyond me how this bug could have made it to another version. This bug alone requires a fix and an upgrade for both 2016 and 2017 immediately.