From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

Post an idea

View All (3)

View All (2)

See Also

Simulated Devices in TestStand Workspaces

Project and Workspace Context in MAX

Link to those ideas in next post

We can already create tasks, channels and scales in a LabVIEW project but, We cannot then use MAX to run those Tasks and we must use MAX to create a simulated device on a development machine. After a few projects the Max configuration becomes cluttered. Deployment and importing of the hardware configuration can get problematic to say the least!

On the other hand- if the Hardware, Data neighborhood and IVI session set-ups could be added to the project deployment would be a snap! just import the *.nce from the project without having to create one from MAX and exclude items not concerned for the project we are installing.

For integration and station troubleshooting the Sessions, Aliases, Tasks et al would be organized by application or project in MAX and fault identification has all the "tools" any repair tech could want to isolate a failure.

When I build a LabVIEW application, I do not include the runtime engine in the installer. Instead, I have a separate project that builds an installer for all the runtime components my applications need. That way, my users can perform the runtime installation once and then update the app separately many times. This keeps my installer sizes small and easy to distribute.

One issue I run into is when I move to a new version of LabVIEW. I need to make sure all my users update their systems to the new runtime engine before they try to install and run my latest release. Unfortunately there is no way to enforce this in the installer. You can check for an installation of the LabVIEW development environment (see image) but that is not very useful.

So, my idea is to add the option to check for the presence of the runtime engine for the version of LabVIEW you are using to build your installer.

Additionally, it would be nice to have a way to check for other required components, such as .NET versions or other NI runtime components or drivers. This is similar to an idea I posted a while ago here.

View All (3)

I remember this in previous (pre-8.2) versions of LabVIEW - not sure why it was removed. I have a use case to use projects as templates (like when someone wants to write a plugin for a utility I've written, I want to be able to send them a zip containing a project, methods, etc). The project includes installer settings (so their files go into the right place under my util's plugins folder, but when they build and try to install their plugin, they get an error if another plugin bult using the same template has already been installed. This is because the "Upgrade Code" (stored in the lvproj file) is the same (it tells Windows that the two products are the same, so subsequent installs are seen as upgrades or replacements, not new installs.

My memory tells me that I used to be able to hit a "Generate" button somewhere which would give me build a new code - all I'm asking for is that back (I can add a step in my work instruction to hit that button before you build).

I don't currently have a workaround for this (other than having engineers manually edit the lvproj file) - if anyone has a better idea, I'd love to hear it for the interim!

View All (2)

A lot of engineers prefer Linux over Windows and would use it on there test machines if at all possible. Instead of attempting to support a wide variety of flavors, wouldn't it be better if NI would derive it's own flavor from an existing distribution and committed to having full support for all NI software and hardware for this new flavor. This would give Linux aficionados the OS they crave and NI the power to control the direction of the OS such that it makes hardware and software compatibility easier.

View All (2)

As software versioning becomes more and more popular also the automatic building of source code becomes more and more interesting.

Right now in our company we are using GIT and JENKINS for C-code material as our versioning and automatic build tool. As soon there is something being checked in and pushed to the main repository the builder gets notified and tries to build your source code having the output available somewhere.

As we are having many users around the globe these tools obviously run on a virtual machine or server somewhere.

Right now there is no option in buying the application builder seperatley and control it via command line. The only option is to put a complete development environment on there which is useless and a waste of money.

My request would be to sell the application builder seperatley for these purposes OR figure out an alternative way for doing this in a professional and neat way.

some usefull links:

http://jenkins-ci.org/

http://git-scm.com/

View All (4)

In newer LabVIEW versions, we can build executables that require SSE2 support an this option is even the default.

If we built an installer, we can select many other system requirements, such as the minimal OS version or the presence of the LabVIEW development system. However, there is no option to prevent installation if the CPU does not support SSE2.

This means that an application that requires SSE2 support will install just fine on a non-SSE2 system and will fail only once we try to actually run.

I suggest to add a system requirement option to the installer builder so the application will not install if the hardware is not suitable. It should maybe even be enabled by default.

Here's how it could look like.

View All (1)

Situation:

I have to support several production lines which are using different LabView versions (currently LV 8.5.1 and LV 2009). On my office PC I would like to use always the latest LabView.

If I open a project which was created in LV 2009 in a newer version of LabView, LV will try to convert all files to the new version. If I transfer it back to a PC which uses LV 2009 I can not open it.

Suggestion:

I'd like to suggest a new project parameter that changes to storage format of all the files contained in the certain project (excluding those coming out of the LV program folder and maybe from some other excluded folders).

View All (8)

View All (2)

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)

NXG needs an Idea Exchange. The feedback button is a lame excuse for a replacement. Why?

I can't tell if my idea has been suggested before. (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
Many ideas start out as unfocused concepts that are honed razor sharp by the community.
This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

View All (2)

I use the Labview Development Environment usually on multiple PCs (my working place, my laptop, the customers development PC, etc.).

It takes a lot of time to install the whole environment and I think nothing can be done about. But it always angers me that there is no way to transfer the settings so that the environment behave exactly the same.

It should be possible to transfer the following settings easily:

- user.lib

- all changes done to the labview pallets

- settings in the configuration

- user added templates (VIs and projects)

and so on

Mayby that should work like the Easy Transfer Function for Windows from Microsoft.

This would speed up the installation and on every system I could experience the same behaviour of the development environment

View All (2)

Add an option in the installer build to run cleanup-programs during uninstall.

On the advanced tab in the Installer build there is an option called: "Run executable at end of installation", but there is no such option for the deinstallation.

We use the existing option to run a batch file that installs and starts the application as a service. If the user decides to uninstall the application we would like to run another batch file to stop and deinstall the service - but there is no option to run an executable during deinstallation.

View All (2)

<bakground>So i just had a silly thing happen to me, i compiled a program and deployed it to the target computer, just like i did yesterday. Then it started complaining about a missing LV 2017 Runtime ... How? Why?

I reinstalled, repaired and it didn't help, both program and RT, several times and it didn't help.

I tested another program which started just fine, so what's missing? Is it some sub-package that my custom RT-installer didn't include?

I called NI and the support technician couldn't see anything wrong either, so with him on the phone i went to the development computer to look at some installer settings he had dug up. That's when i noticed i was in LV2017 64 bit! The messages said nothing about that! </background>

Suggestion:

Improve error messaging when missing RunTime. Include the bitness that's missing, now it only said "Missing LabVIEW RunTime 2017", if it had said "Missing LabVIEW RunTime 2017 (64 bit)" i would have reacted and understood directly, now it cost way too much time to admit. 😕

Also, isn't it time to scrap the 32 bit version and go only 64? 🙂

View All (1)

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)

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

Installer build spec option: Let User "Run Installed Application After Installation Completes"

Change Registered Owner and Registered Company

While creating an installer, make it possible to add Registry keys with all possible types

Simulated Devices in LabVIEW projects

Installer should check for runtime engine

Allow us to change the "Upgrade Code" in an installer

NI flavor of Linux

LabView should provide more options during installation

Labview application builder should be seperatley available for automatic building tools like JENKINS.

Installer Builder option to require SSE2 support

Automated LabView version cross saving

Add option to the application installer to prompt the user if ini file should be replaced

Developer Suite Installer Enhancement

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

Idea Exchange for NXG!

Downloads & Distribution

Transfer Labview Development Environment settings from one installation to another

New Installer Option: Run executable at start of uninstall

Improved error message when missing runtime

Provide a "Remove NI Software From PC" Tool