Home Community Idea Exchange LabVIEW Ideas : New Ideas

LabVIEW Idea Exchange

Community Browser
cancel
Turn on suggestions
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: 
Post an idea
0 Kudos
kosist90

Configure Firewall while installing LabVIEW

Status: Declined Submitted by Active Participant on 04-09-2018 04:16 PM 5 Comment

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...

4 Kudos
kewal

Option to migrate VIs installed in a previous version LabVIEW folder to new LabVIEW installation

Status: New Submitted by Member on 02-27-2018 11:30 AM Comment

This is in addition to New LabVIEW Installation Retains Options

 

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)
  • instr.lib
  • user.lib

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.

View All (1)
8 Kudos
jsiegel

Show better version information for package dependencies in NI Package Manager

Status: Completed Submitted by Member on 02-05-2018 09:16 AM 3 Comment

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 v1.0.0.0 depends on LabVIEW NXG v1.0.  But the installer indicates the version of LabVIEW NXG to be installed is v 4.9.3.49152-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.

 

Review.png

 

(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:

 

Review 2.png

9 Kudos
Bob_Schor

Provide a "Remove NI Software From PC" Tool

Status: Already Implemented Submitted by Knight of NI Knight of NI on 01-11-2018 09:27 AM 14 Comment

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 ...

 

Bob Schor

View All (3)
15 Kudos
kewal

Handle invalid characters in filenames during build

Status: New Submitted by Member on 12-07-2017 05:15 AM 3 Comment

NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:

LLB.png

 

However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:

Build Error.png

 

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:

http://downloads.pickeringtest.info/downloads/drivers/IVI/

Therefore every time we install a new version of the driver we would need to rename the VI filename within the LLB file.

View All (3)
13 Kudos
SudhaLaVen

Single file installer

Status: Duplicate Submitted by Member on 12-01-2017 11:20 AM 2 Comment

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.

7 Kudos
Yamaeda

Add Icon Editor to Program menu

Status: New Submitted by Proven Zealot on 09-25-2017 03:31 AM 3 Comment

With LV comes a decent icon editor. It's the one that starts when you look at Build Application settings -> Icon -> Icon editor.

This seems to be the only way to start this program, there's no entry for it in the Programs Menu.

So what i've done is to create a shortcut to iconedit.exe and add it to my Programs Menu, and i feel this should be part of any and all LV installations!

 

So: Add an icon to Lv's Icon Editor as part of the installation.

 

/Y

0 Kudos
juanmiguez

Multi-Board FPGA Generator

Status: Declined Submitted by Member on 08-28-2017 10:48 AM 2 Comment

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.

 

 

View All (9)
34 Kudos
Hooovahh

Have Post / Pre Build VI For Installers

Status: New Submitted by Proven Zealot Proven Zealot on 08-25-2017 02:07 PM 2 Comment

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.

 

 

EXE settings

EXE Builder Settings.png

 

 

Installer Settings

Installer Settings.png

 

 

5 Kudos
xl600

Add Batch Installer Builder to App Builder

Status: New Submitted by Active Participant on 07-27-2017 01:46 PM Comment

Incorporate NI Batch Installer Builder into the general application builder suite.

 

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.

 

Specifically:

 

  • 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.

View All (2)
0 Kudos
LarryO

No Prompt for "Open/Create/Replace File" function Mac 2016 2017

Status: Declined Submitted by Member on 06-27-2017 09:21 AM 1 Comment

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.

7 Kudos
A.Sasaki

Driver Version Selectable Web-based Downloader

Status: New Submitted by Trusted Enthusiast on 06-07-2017 08:59 PM 1 Comment

It is nice if one can select which driver to download, specifying the version.

 

Currently it is only "Device Driver" item in the web-based installer. By using this option, user must download very huge driver ~10GB.

 

LabVIEW 2016 Platform (web-based installer).png

 

It is very helpful if one can select only necessary drivers like the UI of RT software installation which allows users to choose version such as NI-XNET 16.0, 16.1, or 17.0

0 Kudos
Badri.S

Upgrade LV Application Installers

Status: Declined Submitted by Member on 03-20-2017 01:56 PM 3 Comment

Hi, 

If we got an option to auto upgrade all the deployed executables in the network. In case of new version is getting released. Like the update features avaliable in all mobile applications.

 

This will be very useful in case same application is being deployed in many places and needs to get upgraded after the new release.

 

Thanks,

Badri

0 Kudos
Alexander_Sobolev

Read-only labview license

Status: Duplicate Submitted by Active Participant on 01-19-2017 05:08 PM 2 Comment

Would it be great to have free labview license that would allow to read VIs and save them to the previous version you have?

Immediate upgrade to new version does not happen in my case. I can not justify it for my boss, it adds a lot of work to upgrade all customers to new version, I hate idea of supporting multiple versions of code.

The main reason I need later version(s) is forum posts, other solutions that I would be able to open, save to the full one for real use. May be I will see the beauty of VIs in new versions and agree to upgrade 😃

0 Kudos
cy...

New additions in instr.lib folder to be defaulted to read-only

Status: Declined Submitted by Active Participant on 01-12-2017 09:00 PM 3 Comment

Hi

 

Is it possible that the contents within the instr.lib to be defaulted to read-only every time LabVIEW launches? VIs that is drag-drop from the pallet onto block diagram is currently modifiable and may cause unintentional code modifications, especially due to the 'save all' function and hasty/improper shutdown. The extend of the damage may be inherited over time.

 

Also propose to default modified instr.lib VIs saves to be in active project folder instead of the instr.lib.

 

Hope to see these features in future versions.

7 Kudos
Bob_Schor

Expand Programmatic Control of Build Process

Status: New Submitted by Knight of NI Knight of NI on 01-01-2017 04:29 PM 2 Comment

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 ...

 

Bob Schor

View All (3)
0 Kudos
A_G_R(E)

Get the path of the installed application by the installer

Status: Declined Submitted by Member on 09-23-2016 10:08 AM 4 Comment

The purpose of this is the user saves time creating installers  that have the same application but theirs configuration files are different.

1 Kudos
matt.baker

Stop using removable drives as a temporary location for installation

Status: Declined Submitted by Active Participant on 08-01-2016 07:55 AM 4 Comment

Please can the installer be changed to stop using removable drives as a temporary location for installation files. I had a 2TB drive attached when I started the install and "safely removed" it part way through. The install then failed Smiley Frustrated

I assume it uses the largest attached drive available. If possible could it check for the fastest drive instead. My main drive is an SSD with an HDD as the secondary drive which is larger. The SSD would have been the best choice in this instance.

9 Kudos
cyphish

Increase download speed

Status: Declined Submitted by Member on 07-15-2016 07:02 AM 6 Comment

 

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.

 

8 Kudos
oskretc

Add LabVIEW installers to chocolatey

Status: New Submitted by Member on 06-11-2016 03:09 PM Comment

Chocolatey:

The package manager for Windows (like apt-get but for Windows). https://chocolatey.org

 

Chocolatey it's a command line tool to download and install software with focus in automation and unattended..

 

something like:

 

choco install labview

 

and after a few coffees, voila. All installed.

 

it also supports local files, e.g.

 

choco install labview --source d:\

 

in case you have the "package" in the d drive.

 

 

Installing NI drivers should be something like:

 

 choco install NIDrivers               //full installation

 

 

choco install NIDrivers.NIDCPower            // Only NIDCPower 

 

Toolkits could be handle in the same way.

 

Chocolatey also handles dependencies. So requiring LV before installing any toolkit should be straight forward.

 

 

View All (3)