LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

According to the LabVIEW 2013 readme file (see attached image), NI installs a so called NI Launcher to work around serious shortcoming in the Windows 8 start menu. 

 

This is an essential tool because the Windows 8 start menu is flat (non-hierarchical) and if there are many NI products installed, the "all apps" screen shows pages and pages of tiles of e.g pdf help documents and it is impossible to find anything without scrolling forever.

 

Unfortunately, the NI Launcher functionality is quite limited to what we were used to be able to do in e.g. the Windows 7 start menu. All we can do is browse and launch a NI application.

 

While the readme suggest to pin often used program to the desktop, taskbar, or start screen, we can only do this by finding the icon on the Windows 8 "all apps" start screen first, where we can easily get lost if many NI products are installed! Yes, believe me, it is very tedious!!!

 

I suggest to add several right-click options to each entry directly in the NI launcher (similar to what we see in the windows 7 start menu):

 

  • open
  • pin to task bar (very important!)
  • open file location
  • troubleshoot compatibility
  • run as administrator
  • pin to start menu
  • ...
  •  (anything that is easily possible to implement)

 Idea summary: NI Launcher should have right-click options for each entry similar to the Windows 7 start menu.

 

 

 

 

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/B43C655BA37AFFA0862575EC0051E936

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. 

The last decade has seen a fantastic development in using neuronal networks to analyze data. Neuronal networks allow doing nowadays feasts that were unimaginable a decade ago at a tremendous speed. The latest release of LabVIEW allows using old TensorFlow versions <= 1.14. About four years ago, TensorFlow switched to TensorFlow 2.0, which resulted in a significant transformation in how models are organized. Models developed in TensorFlow <2.0 are incompatible with current standards. If National Instruments aims to maintain its position in the market of computer vision, developing tools to use current TensorFlow versions is a MUST.

 

Add ability to install and update NI packages via the winget utility.  This would make it easier to standup new development or test systems. 

 

Winget has a very user friendly export/import systems that can be used to replicate development installs across multiple computers. 

 

tkendall_0-1662655723758.png

 

I think you should be able to build this around the current NI package manager system with some helper scripts. 

 

The latest release of the Vision toolkit (Vision 2012 SP1) provides some much needed improvements to the AVI functions.

 

But at the same time, it introduced a new issue:

 

"The Quality input in the IMAQ AVI2 Create VI is only implemented for Windows
codecs. The Quality input is not implemented for codecs installed with the
Vision Development Module."

 

This is very unfortunate, because it worked fine in the previous release (see here)!  This means you may want to reconsider upgrading to SP1!

 

My idea:  Fix this!  Re-allow the use of the quality parameter in the AVI functions so we can better compress our video!

Add power point added to the programs supported by the report generation tool kit. 

One of the biggest issues that I see new customers run into is the proper install order of LabVIEW and it's drivers.  It's not directly obvious to most that you HAVE to install LabVIEW before the drivers.  When they install another version of LabVIEW and do not update drivers, or they accidentally install drivers first nothing works correctly (DAQmx VIs don't appear in the palettes, New>Targets and Devices doesn't appear in the project menus, etc).  The solution to this is to completely uninstall the drivers that were installed, and then reinstall them.  This is annoying and takes a long time. 

 

My proposed solution would involve an easy "repair" option or tool that will simply reconnect the components and VIs etc to avoid the massive headache that most new users seem to get themselves in.

 

While NI provides (thank you) reasonable support for OS X these days, the support for installs and updates "on line" are very far behind those for Windows.

 

For instance, there does not appear to be any option to download Labview 2010 for Mac but I can for Windows.

 

 

It would be nice if LabVIEW automatically check for updates and notifies the user of all of the upgrades available for everything that they have registered. It would be nice if patches were just down loaded and installed much like the Windows Updater function. It would keep LabVIEW, all of the tool kits, Measurement and Automation Explorer, and every licensed software up to date. It could also push down labview as long as you are on the subscription and current.
Builder should automatically attach version of LV to EXE so it can be seen in Windows Explorer. So you can always ask unexperienced end user about version. I drove 1000 km with wrong version of LV on my laptop... Upgrade to new version is not always straitforward... And I always forget to set version information manualy...

When you install LabVIEW and MAX configuration support for DAQmx (and other components are the same) the NI Package Manager adds a number of other LabVIEW runtime versions to the list of dependencies.

When I install support for LabVIEW 2019, the package manager add LabVIEW 2014 and 2018 runtimes.

 

Surely this can be tidied up!  Please tidy up dependencies.

 

If I only have LabVIEW 2019 installed on my system, I shouldn't need the LabVIEW 2014 and 2018 runtimes to make a 2019 component work.

It would help to have an option to ignore Bad VIs errors when calling a mass compile via LabVIEWCLI. This makes the CLI MassCompile unusable for deploying code with NI Package Manager that has API Tree VI. It would help to have an option to ignore those errors so that NI Package custom execute could run successfully. I would think it could be defined as optional argument. My suggestion for the argument is -IgnoreBadVIs true|false with a default of false.

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.

Hi !

 

Often dealing with old code it's always a pain to install old versions of LabVIEW to get the code compiled the newest LV version.

For example, porting code made in LV 5.0 implies converting first to LV 7, then convert to LV 2009, and finally convert to LV 2013.

You then have to install these version, licences, ...

 

It would be nice to have a service on NI.com website from which we could send a zip archive containing the project to convert.

Then selecting the target LV version, a could service could unzip and compile the code across all versions of LV to have the code matching the requested version.

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.

Would like to see LabVIEW implement "Cloud Preferences". Basically store the LabVIEW.ini file in my NI.com account and be able to log into LabVIEW and have it download the ini and use it. Even allowing it to be *easily* stored on the network would be an improvement.

I would like to suggest implementing the capability to add a bulk of users or computers in Volume License Manager. I suggest to allow a text (maybe csv or similar) file's content to be imported in, which would greatly speed up the setup of a new VLM server. Addionally, for the adding computers, it would be good to discover all PCs on the network and allow the administrator to select the computers to add using a checkbox.

At my current work place we use proxy servers as an internet connection. With LabVIEW it makes it difficult not only while the NI software is being installed (to check for updates, connect with server for veryfication etc) but also during typical work it makes troubles with finding examples and drivers from a development enviroment.

 

I would suggest adding some advenced internet connection options for proxy settings etc.

 

Another little thing with a company computers is that, even when installing NI software on a D drive it still installs some example software on C:. It makes problem when your IT limited your C drive for absolute minimum, because with huge amount of NI software the amound of "additional" data is getting bigger and bigger.

 

Regards,

 

PacHOOk

LabVIEW opens the file in the version of LabVIEW that was most recently opened instead of the version the file was saved in.  Add a header to the file to allow LabVIEW to open the file in the correct version.  This will save a lot of time and lower frustration of accidently saving a file in the newer version.

I haven't checked out LV2009 on Mac yet, so please let me know if this has already changed.....

 

When creating an installer on Windows, we have control of everything within the Project.  Cereate EXE, then create Installer with all options within the project.

 

On the Mac we have the options for the Application but not for the installer.  I know (After I spent a day looking for products) that Apple has an installer packager which ships with the OS (On the developer CD) but why can't we automate this from within the Project shell?  As it is I need to create the Application, then switch to an external program, create the installer (luckily it's relativel easy o use) and then to finish things off go to ANOTHER pogram to create the dmg file.

 

Please give the Mac the same Installer creation options as Windows.

 

Shane.