LabVIEW Idea Exchange

Post an idea

In LabVIEW IDE, when configuring executable build specifications, under "Version Informtion", it could be greate to have a string control to store free information depending on our version numering management (ex: alpha, beta, release candidate ...). This value could be used as a postfix to the 4 digits version (ex: version "1.3.0.1 alpha 5").

In "Details" tab of Microsoft Windows executable files, the "Product version" metadata is a string so there should be no problem.

Download All

Currently, if a new version of LabVIEW comes out with new shortcut menu plugin or a quick drop shortcut, that is written in LabVIEW the only way to have that added for older, still supported versions is to save them to for the oldest version, and copy them to the respective folders.

I wish, that the new features in these categories would be available trough download for the supported LabVIEW versions for everyone that has a license.

I would love, if these were separated into their own package, that is a dependency of the LabVIEW installer, but could be updated later from the package manager.

View All (3)

I wish LabVIEW had Official Container (Docker) Images.

With more and more users trying to use the docker in Continuous Integration, it would be

interesting supporting a NI Official Image on Docker Hub (or any other place). Containers provide an easy way of creating reproducible tests and builds.

The build of LabVIEW docker images has been feasible since NI Package Manager command line was launched, and for NI wouldn't be a new thing.

The advantage is that the images (Windows, Linux or Mac OS) could be optimized by NI team only for working for LabVIEW, shrinking size and removing unused files.

Anyone else would support this idea or has anything to complement?

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.

View All (3)

Problem

Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.

Idea

I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.

View All (4)

Having sold applications that use functionality from the OPC UA Toolkit we run into an issue if we upgrade our LabVIEW version and continue to develop those applications beceause the OPC UA deployment license will then stop working if we upgrade the software we have delivered to them to one developed in a newer version. So, even though the customer has an OPC UA deployment license and we have an updated developer license it is not enough because the deployment licenses have to be updated as well (and it does not help that deployment licenses are not something we can bunde with the upgrade of the software either). From what I understand new deployment licenses will not actually cost anything, they are provided by NI as long as you already had a deplyment license for the previous version - but the logistics of this is a nightmare for us. Instead of just delivering a new installer with an updated version of our software we have to get involved in upgrading the dpeloyment license for all of their systems each time we have gone to a new version of LabVIEW.

View All (4)

Yup, Upgrading LabVIEW versions takes a day.

The "Process" today is:

Install from media
Configure the new LabVIEW.ini
install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
Mass Compile all them......
Fix palatte views... and import and mass compile User.lib\ for here.....
Sync glyphs on the icon editor (If the link works......)
Add VIT's
Add Project Templates
Mass compileVIt's and Templates
fix "Metadata.xml"...

Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

View All (1)

The Problem:

When storing many builds of installers, currently there is no easy way to find out the version number of the exe that the installer installs.

In the past I had tried to work around this by programmatically setting 'Installer Product Version' to the same as the exe in my build script. Installer Product version can be found in the installer's nidist.id file under [Volume Id]>DistributionVersion, and the setup.ini file under [Distribution]>Version. This works nicely until you want the build number, or major/minor exceeds 255: 'Installer Product Version' is stored in the format major.minor.fix and the max values are 255.255.65535 i.e. u8.u8.u16. This is a limitation of MSI installers. See:

Version Information Page (Installer Properties Dialog Box) - LabVIEW 2018 Help - National Instruments
ProductVersion property - Win32 apps | Microsoft Docs

Executables have Version Numbers in the format major.minor.fix.build, with max values 65535,65535,65535,65535 i.e. u16.u16.u16.u16

I would expect the installer's setup.exe's File version (under Properties>Details) to be settable as major.minor.fix.build, but this is not the case. File Version seems the most appropriate as it is 4 digits and this is used in built exe's. I would like this to be settable via property nodes (in the same way as .exe's) as it does not have the u8 limitation and does not omit the build number. Currently property nodes do not affect it. If numbers larger than the u8/u16 limits are set via property nodes, they max out in nidist.id and setup.ini. Another acceptable workaround would be to include another key/value pair in nidist.id or setup.ini that allows u16 major.minor.fix.build to be set via property nodes.

Proposed Solution:

Property nodes affect the installer's Setup.exe version number under properties, with max values of u16.

Or there is a new key/value pair in nidist.id or setup.ini that allows u16 major.minor.fix.build to be set via property nodes, in addition to the existing key/value pairs that have some u8 max values and omit build number.

Perhaps this will no longer be an issue if NI moves away from MSI installers...

View All (2)

Could it be possible for LabVIEW (even if only for versions 202{1,2,3} onwards etc) to make an attempt to open newer files and just break them when new features are used?

The comments in this Idea (LabVIEW Compatibility Modes) suggest this and related ideas, but it isn't the main part of that idea, so I'm posting it separately here.

An ideal solution for me would be for VIs to automatically save back in the 'oldest' version that they would support (and perhaps not be 'up-compiled' on load), but this idea has been discussed a few times and doesn't appear to be something NI will support.

An alternative (perhaps only possible in currently unreleased versions?) might be to have LabVIEW 202x try and open a VI saved in 202<x+n>, and then give the symbol for missing VIs (ideally with the name, if possible) for anything that isn't supported.

As an example, trying to open a VI using Insert into Map (if this were available for existing LabVIEW versions) in LabVIEW 2018 could produce something like

with the Context Help giving me a clue as to what was lost - I could then Google "Insert into Map LabVIEW" and try guess how I might replace it (here, probably with Variant Attributes).

I'm posting this idea in relation to some comments I've recently heard regarding sharing and packaging code with LabVIEW, and how even when other (text) languages add new features and so code using them will fail to compile, their users/developers can still open the code, try fix bits, or generally workaround issues (and evaluate the benefits of upgrading, if the changes are large).

New versions of LabVIEW continue to have significant new features, so upgrading seems like it will continue to be at least my preference, but not everyone has the same requirements/situation/SSP/blah blah blah.

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.

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

View All (11)

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)

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.

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

I am a big fan of LabView! This idea is meant to be a positive suggestion, and I hope it will be taken as such.

I almost wish this post was in jest; it is not. This is a serious suggestion that, in my opinion would improve the NI LabView program, save cost, and be much better for the environment.

I recently purchased Application Builder for LabView (both Great products). I received my Application Builder via FedEx. It comes in a very nice looking heavy mailing package with the bold label "NI LabVIEW 2010 Add-On Software. I think there must have been a FedEx overwrap with the following forms:

-Printed shipping manager page with the FedEx Bar Code

-Printed packing Pick Slip (two pages) with a certificate of conformance on page 1 of 2 and a signed page 2 of 2 by the Vice President of Quality and Continuous Improvement (I am not making this up)

Now, inside of the envelope is

-The standard folded yellow installation instruction page

-A certificate of ownership! (same serial number as is printed on the outside of the heavy mailing envelope)

-A card which says (really!) "Where is my Media?" The card says: "In an effort to reduce the impact on the environment, National Instruments no longer ships media with these kits.

Now, I assume by this point everyone sees the irony here, and where I am going with this New Idea for LabView!

IDEA: Upon successful purchase and proper payment of a LabView Add-On Software package: Email the serial number to the authorized user.

Optionally (if required by legal), send the paper Certificate of Ownership (one page!) to the authorized user, or if allowed by legal, Email a PDF of the Certificate of Ownership to the authorized user.

Savings:

Beautiful outer envelope and stack of printed pages made in Ireland - Well, not needed (Give them other work, I don't want to see lost jobs)

Shipping cost and impact on the environment (Ireland to Austin) SAVED

Storage cost and space at NI Austin SAVED

Shipping cost and Air Freight Austin to end user SAVED (less jet fuel impact on the environment)

Less paper to be recycled by end user SAVED, positive impact on less energy needed for recycling!

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

Executable version string can have a free postfix (alpha, beta, release candidate ...)

Make the new shortcut menu and quick drop plugins available trough download for older versions

Official LabVIEW Docker Images

Tensorflow 2.x

Install LabVIEW API ONLY for NI Drivers

OPC UA deployment licenses should be version agnostic

Permanent Knight License

MyLabVIEW

Expand (or allow expansion of) NI software installer GUI

Installer Version Number under Properties should be Major.Minor.Fix.Build

Make a 'best-effort' attempt to open newer VIs/LVLIBs/etc

NI packages installed though winget

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

Segment the LabVIEW Run Time Engine (RTE) to ONLY Necessary Components

Include longstanding "known issues" in the help file

Upgrading Labview From Old to New Versions - Not Easy!

Have Post / Pre Build VI For Installers

Reduce Impact on the Environment

Rewrite MODBUS library

Warning when saving in LabVIEW later Version