LabVIEW Idea Exchange

Post an idea

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.

One of the more annoying features (see also here) is the unzip operation after downloading a LabVIEW distribution. As a first step, it will unzip somewhere into the "National Instruments Downloads" folder.

Of course it will place the progress window right in the middle of your monitor. Typically this takes a while and actually want to do something else and move that window out of the way, so we can still watch it in the corner of the eye. Easier said than done! A simple click in the window header pauses the unzip operations and asks if I want to abort... NO!!! I simply want to move that window is the same way I can move any other window from any other application!!! Why that nonstandard behavior? Just to annoy us??? Here's what happen if I click anywhere near the top edge of the window:

When we righ-click the window header, we see two options "(1) move" and "(2) close". Why is close the default??? If we really want to close, the [x] button is right there another inch to the right and nobody should have trouble finding that spot. If I click elsewhere in the header, I most likely want to move that window!

In order to actually move it, I have to right-click the window header and select "move". That seems silly!

IDEA: The unzip window should should be less annoying and easy to move elsewhere. Thanks!

Is it possible to have a USB dongle license option rather than a registration key?

When the USB dongle is attached the user will have the full access to the Labview Version s/he has registered for, when it is not the program will only run in runtime engine mode. The advantage of this is that it would allow for system developers of multiple systems to be able to debug and test programs on the machines without needing to either have several licences or continually uninstall and reinstall labview from the machines everytime a change in the software is required.

At the same time, a USB dongle can only be used on one machine at any one time, thereby making it possible to ensure that there will not be more than one user of the same license.

I've seen this work for several small software companies as well as hardware companies with proprietary software. Why not for Labview?

Just a thought,

Karl

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.

(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

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)

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.

View All (3)

LabView uses the "primary" MAC address to identify a machine. If the MAC address changes, LabView assumes the software no longer has a valid activation and displays the following:

Like many developers, I have to use a VPN to connect to a corporate network. My VPN client creates a pseudo-interface with a (random?) MAC address each time I connect. LabView inspects this MAC address and decides I've installed LabView on a new machine, forcing me to go through the activation process again. I have to activate LabView about every 10 days. I have contacted support about this, and they have given me various work-arounds such as non-expiring activation codes (which required manually entering 10 activation codes, one per product, and only work until the next LabView service pack), or tying activation to the Disk Volume ID, which frankly I did not bother trying since the "eligibility on a case by case basis" did not mesh with the reality that every point release of LabView requires re-activation.

Now, I don't want to make too much of this. I've never had the activation fail, and it is pretty fast, so it's really not a big deal, but it is kind of silly to identify a machine based on a mutable property. Heck, on linux it's trivial to change the MAC address to anything you want! (I tried this with my VPN client, but it had none of it.)

I suggest the activation process something more stable, like the CPUID on Intel processors or, barring that, restricting the MAC address search to physical interfaces.

Thank you!

Rob Calhoun

When you try to open VI saved with later version of LabVIEW, you get this error :

Sans titre.png

But when you open VIs in a given version with a later version of LabVIEW, you have no information and that could cause big problems.

For many reasons I have to work with different versions of LabVIEW (right now I have 8.6, 2010,2011 installed at the same time), and it's a major problem when I open a project and by mistake choose the wrong version of LabVIEW.

Someone proposed to display a saving selection popup Here

But when you have already made some modifications, it's enoying to discover that you won't be able to save it.

I propose instead to display a message when opening a VI, and let the user chosse either he want to upgrade is VI version or not.

At least he can see his mistake and decide to open the VI with the good version of LabVIEW.

Hi all LabVIEW fellows and users,

I know this has been asked many many times but one more might still help getting it.

Everybody agrees to say that today LabVIEW has became a great general purpose programming environment not only dedicated to test, measurement, instrument control or data analysis but able to manage virtualy any kind of requirement which is very cool for us LabVIEW programmers.

However, to my opinion one thing is still slowing down the use and spread of LabVIEW for developping general purpose applications that is the HUGE SIZE of its run-time engine!!! An average executable size for an application ranges from 1mb or less to 10 or 20 mb for quite large applications. The run-time for being able to execute it is at the very least 10 to 20 times larger which makes it very difficult to release over the internet.

I recently created a small application that monitors the state of the caps and num lock key and indicate the state with a tray icon since my computer is not equiped with those LEDs. I know some other users would appreciate to have that little piece of code since they might experience the same problems I had. How can I explain them that the application and installer is about 200 MB for such a tiny little piece of code? Don't you think people might believe that the proposed application is stuffed with malwares of that there is a BIG probleme with it?

Please dear NI decision makers make LabVIEW a "real" general purpose developping environement by adjusting the installer size to only what is required for the application, the whole community would appreciate so much at least make this option selectable.

Hope this will be listened.

Best Regards,

Brice

View All (2)

For all NI software that has an evaluation license available I propose that instead of a number of days the evaluation would be good for a number of hours. Whenever the software detects user activity it will start to decrement the hours remaining. If no activity is detected after some number of minutes the timer will stop decrementing.

I installed the Test Stand evaluation and ran out of time even though I only got to play with it for maybe a few hours. I did get an extension from our sales representative. I am hoping I will get the time to thouroughly check out this software before trying to get funds from the boss.

This idea is not specific to LabVIEW but all NI software for which evaluation licenses are available. I am posting this here since the LabVIEW idea exchange is the most visible.

The Registry Settings within the Build Spec from an installer is using fixed values only.

It would be nice to have somthing like varaibles that contain the information that are entered on the page
"Productinformation" in the settings window from the installer.

Productname -> %productname

Productversion -> %productversion

User selected Path for installation -> %installdir

This would allow something like this:

The values {%productversion} etc. will be replaced during the setup with the real values. The %installdir contain

the selected installation dir from the user.

View All (3)

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)

So, having a new computer and installing the 4 versions i currently need i ofcourse missed to reinstall DaqMx after the last and most important LV install. After alot of time i managed to get hold of a disc, ofc slightly lower version so i first have to uninstall my current DaqMx ... this cost alot unnessecary time, when e.g. MAX should be able to add/complement itself to installs.

When i run the installer, it feels which versions of LV has Daq and which doesn't, it'd be great if you could add/complement Daq to LV's without having to reinstall it!

If this is best handled by MAX or some DAQ-installer i dont know, but as MAX feels like a hub it sounds logical to add some Update/Add/Attach DAQ-function to that.

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.

View All (4)

View All (3)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

Increase download speed

Make "move" the default action for the unzip window when clicking the header

Alternative Licensing option

Show better version information for package dependencies in NI Package Manager

Add LabVIEW installers to chocolatey

Expanding Linux Support

Product Activation Should Use Stable Machine Identifier

LabVIEW version alert

Reduce LabVIEW Runtime size to only what is required for the *.exe to run

Create shortcuts to folders when configuring an installer

Time Based Evaluation Software

Application Builder, Installer Registry -> allow variables like %productversion, %productname, %installdir in the Registry

Remake For Loop

Add Icon Editor to Program menu

Driver Version Selectable Web-based Downloader

Expand Programmatic Control of Build Process

Smart DAQmx/MAX

NI Launcher improvements (Windows 8 only)

Windows Shortcuts (.lnk) Become Part of LabVIEW Expected File Path

LabVIEWCLI: Add Refresh Palettes Operation