LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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

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.

Increase download speed

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.

Add LabVIEW installers to chocolatey

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)

Uninstaller improvements

Make it easier to find the right product in the uninstaller

If you install a lot of National Instruments developer tools the uninstaller becomes very crowded. You can have 50-100 components, often with similar names and varying name structure. Finding the component you want to uninstall/modify/repair can be difficult.

The fact that things a split into so many separate components is practical, but the components should be organized better:

They could be:

logically grouped
have descriptions
there could be a search/filter function available (that accepts wildcards)

Allow us to specify a new source location

If I want to repair or modify an installation it might turn out that the original source for the installation is gone, or I have a new (identical/compatible) source that I would like to use instead. It would be nice if the uninstaller handled this, instead of insisting on the original.

Expanding Linux Support

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)

free label format

How often do you find the need to orginize data into a table format while documenting your vi? I for one, could & would use it all the time! Creating a resizable table free label we all use in word & excel seems like a simple task and would aid in organizing and documenting data into a more readable format. A ctrl+double-click or shift+double-click could serve as an easy access method, tab through the contents, and resize rows and colulmns vis a cursor change while hovering at the specific borders. Free Label, New type, table format, organize data, rows, columns.

Although new folders can be created in the application and installer build specifications, they are not created unless a file is put there. An empty folder is desireable for data output. It would be better for it to be created before running the application so that security access rights can be set by the person doing the installation if administration priveleges would otherwise be needed to create new files there. It leaves quite a bad impression on those who waste time finding out by trial and error that the folders defined in the build specifications are not created. The forum also documents complex schemes to work around this limitation by people who surely would rather have been doing something productive instead.

View All (1)

If you install anything (anything!) from NI on a computer that runs windows 8 or newer, you will get bugged by a dialog to disable fast startup. The option is enabled by default, no matter what you install. It will popup with every single install, even minor patches, and even if this option has been intentionally unchecked in the original installation to be patched. If you don't want to disable fast startup, it is a never-ending whack-a-mole of these dialogs. (... but the need to disable fast startup for some scenarios is a more general problem that NI needs to address. It could be a new idea, but I think NI is aware of this problem. It might even be something that Microsoft could address such that devices don't get lost in the scenarios where fast startup causes problems)

This idea is centered around executables that we built and distribute via installers..

While this option (=disabling fast startup) can be useful when certain DAQ hardware is used, it makes absolutely no sense for other LabVIEW programs. Most of my programs don't use any DAQ hardware and it is not reasonable to globally cripple every single computer that has them installed. People tend to click [next] without reading, assuming that the defaults are typically reasonable.

Currently, this install query can be silenced by editing the setup.ini and changing the entry "WinFastStartup=1" to "WinFastStartup=0". I have built dozens of applications over the last few days and it is becoming seriously annoying to constantly remember to do that.

I suggest that the installer builder should get another checkbox that allows us to set that option permanently. Here is how it could look like.

Checking that box will give the current experience where the installer asks to disable fast startup. (it could even be checked by default to mimic the current default behavior)
Leaving the box unchecked will skip that dialog and will not disable fast startup.

IDEA SUMMARY: Allow us to configure the fast startup dialog from the installer builder tool.

Installer enhancement

LabVIEW Projects can use an icon in the exe, but not when running in development, and not in the built installer.

Add to the LabVIEW project to have a property to set a project icon. With the Project icon, when running in development mode, it can use that icon instead of the standard LabVIEW one. Extremely useful when trying to give demos, screen shots to send to customers and building an exe is not working, feasible or designing on the fly. There is a hack you can do using the shell32.dll that on open of any LabVIEW panel, it can rewrite the icon, but then code must be added for any and every panel to show the icon. Also if the window name changes, you have to call the same code again.

The installer also does not inherit the icon from the executable being installed. Add an option to add an icon to the installer and have it embedded in the setup.exe. Also include the registry setting for DisplayIcon = Icon path to exe or to defined icon. I've currently been able to change the setup.exe icon using the Resource Tuner application (www.heaventools.com for $50). It's as simple as changing the IconGroup 128 with your own icon and save the exe. This embeds the icon to show up in Windows Explorer and as the icon when running the installer.

The wrinkle is that the installer does not have any pointer in the Add/Remove list for Windows for the icon. You have to know the ProductID and ProductCode which changes every time you build the installer, as it is in the setup.ini file at the bottom. Going to the 32bit or 64bit registry (depending on what you are installing), you have to add a new string key "DisplayIcon" and it can point to any icon file or the exe using the path.exe,0 to represent what icon to use. The path to the reg key is somthing like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{E851D69F-49EE-4B9C-BAE7-58AB782E801A}\DisplayIcon. I'm currently developing an exe to run after the installation to set the registry key properly. It takes command line arguments for the Product Name (search registry for the GUID), path to icon/exe to set. This way each installer uses the same executable (LabVIEW built) to set the icon in the add/remove list properly.

It should be easier to change the default copyright company in Application Builder.

I got the following from NI support to change the name of the company that is copyrighting the software.

1. To show the desired hidden folder, you must select Tools>> Folder Options >> View >> Under 'Files and Folders'>> 'Hidden files and folders' >> check the 'Show hidden files, folders, or drives' >> Select 'ok'

2. Navigate to C:\ProgramData

3. Open ProgramData >> National Instruments >> LVProductDLLInfo >> 12.0.0 >>LabVIEW_ADE_120000.ini ***Please note that the folder 12.0.0 may instead be 14.1.0 or another numeric value based on which version of LabVIEW you are using***

4. Change the RegisteredOrganization and RegisteredOwner to the appropriate organization and owner respectively.

The fix NI support sent me was to change the name of the current software owner.

The company that owns the software is usually writing the program for another company that is paying to have it developed. If the software owner is not careful they may assign the copyright to their company or to the company that they developed software for last. I am sure that the company that had software developed will be surprised if their name is not listed as the legal copyright owner.

Stan

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

NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.

I suggest that NI start shipping USB keys instead. USB has several advantages:

USBs are smaller
USBs are more usable on devices without DVD player
Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.

I'm about to upgrade from LV8.2.1 to LV2013 and then there is a lot of unsupported properties and methods in the new version.

It would be very nice to have the possibility to find those unsupported stuff.

Actually NI seems to need that function too. smileywink:

Take a look at this thread I made a while ago.

"http://forums.ni.com/t5/LabVIEW/how-to-find-unsupported-methods-2Fproperties/m-p/3032045#M865373"

regards Bjarne

Download All

Getting a value change event on a shared variables seems to me like something that ought to be expected "out of the box" in LabVIEW. Polling shared variables for changes is taxing on resources, and such an architecture is generally frowned upon by NI and the LabVIEW community for things like front panel interactions and the like. Why, then, should we expect to pay extra to deploy applications which such an architecture for interacting with shared variables?

I completely understand the extra license for the DSC run-time, as there are numerous other terrific tools included. It just seems to me that the SV value change events are one thing that should be freely available for deployment to everyone already paying for the application builder.

Thanks!

To be honest, I am not entirely sure what that means. Only that my IT department says NI downloads do not have a valid signature and the firewall blocks them. Currently we are working through this "http://www.ni.com/white-paper/12402/en/" , but I am not convinced the answer is there for us. I am able to download files from any website that I currently use here at work so I don't understand why NI downloads would have a problem. By the way, this is using the NI downloader or using manual download, neither method works. Using other browsers yeilds nothing either. Cruising the internet for similar problems came up with "Software Publisher’s Digital Certificate", is it possible NI's isn't valid or something?

Anyway, seeing as how internet security is just going to get tighter and firewalls more strict, I don't want hokey solution that will just break with another update. Anybody got an answer for this delima?

Robert

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.

My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

View All (1)

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is uncomfortable.

So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past... He! He! He!

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past... He! He! He!

View All (1)

The NI Volume License Manager has a tool to create a volume license installer.

If you want to include Drivers you have to copy them to the installer folder _src\DriverDVD and then modify the nisuite.xml file (depending on license server you run)

There needs to be a simple way to say add NI disc to installer folder. Or at the end of creating the installer it could ask if you want to include other discs.

This should work for adding the driver disc and other extras like the Xilinx Compilation Tools, etc...

That way you can easily put together a full LabView Development install location for users.

LabVIEW Idea Exchange

Stop using removable drives as a temporary location for installation

Increase download speed

Add LabVIEW installers to chocolatey

Uninstaller improvements

Expanding Linux Support

free label format

create empty directory folder in application and/or installer build specification

Give us control over the fast startup setting when building an installer

Installer enhancement

It should be easier to change the default copyright company in Application Builder

Product Activation Should Use Stable Machine Identifier

Ship NI Developer Suite on USB keys instead of DVDs

Finding unsupported Properties/Methods

Do away with DSC run-time license for getting shared variable value change events

Include Valid Signatures with File Downloads

Include longstanding "known issues" in the help file

How many need Delete Option on Context Menu?

How many need Delete Option on Context Menu?

Packed LVCLASS Package: .lvclassp

Create Volume License Installer - Add Discs