LabVIEW Idea Exchange

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

Within LabVIEW Build Specs you can specify a version for an executable that is built.  You can presently see this from within the Windows add/remove program and there are some funky ways of getting this version with .net or WinAPI calls but you should be able to do this from LabVIEW similar to the app version as shown below.

 

appversion.JPG

 

This should also be within LabVIEW so that it can work from LabVIEW Real-Time as well.

The title says it all - I'd like to have the option to inherit my configuration settings from the previous LabVIEW installation (or from a specified path).  Currently I have to do this manually by copying the ini file from the previous version, but I'm never sure whether there will be compatibility issues with the new version of LabVIEW or if there are obsolete settings.  The installer should check for compatibility/obsolescence issues as it creates the new ini file.

 

Alternatively / additionally, I'd like to be able to specify where LabVIEW loads the LabVIEW.ini file from (which could be located on a network or USB disk).

NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:

LLB.png

 

However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:

Build Error.png

 

This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.

 

During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect Channel_.vi"  and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.

 

While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.

 

The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:

http://downloads.pickeringtest.info/downloads/drivers/IVI/

Therefore every time we install a new version of the driver we would need to rename the VI filename within the LLB file.

Currently, if you want to install LabVIEW 64bit, you need to download it from ni.com.

 

My idea is to put it on the LabVIEW Platform DVDs. 

 

It should be there.  I am paying to get my software on a DVD.  Please include it on my DVD.

 

The only reason I can think of for NOT putting it on the DVD, is that NI is worried that inexperienced users will install the 64 bit version (afterall, doesn't 64 sound bigger and better than 32! Smiley Happy), and NI will get tons of technical support phone-calls from the resulting confusion.

One example is shown below from the Device Driver Installation dialog but there a many similar cases. It is very difficult to obtain a decent overview having such a small window for the tree display.

 

I suggest as a general style guide to always enable the resize option in a dialog box whenever the layout requires a scroll box.

 

I have a hard time to see what could be reasons not to do so.

 

dialog resize.png

There have been several ideas proposed to alleviate accidentally savings vis in the wrong version of LabVIEW. While useful, I think the main problem is that LabVIEW doesn't use the information it reads from the file to preserve compatibility. I'd like to propose here that LabVIEW introduce compatibility modes for previous releases in which LabVIEW will break a VI if a feature is introduced that isn't supported by the compatibility version. It will essentially be a built-in, seamless "save for previous" mode. 

 

By default, LabVIEW will load a VI (hierarchy) in a compatibility mode for whichever version is was saved in. If the user tries to make a change that isn't compatible, LabVIEW will alert the user and the user can tell LabVIEW whether it's ok to save to a newer version that supports the feature.

 

The level of alerts can be configurable, of course.

 

Related ideas:

Version-aware LabVIEW launcher

Add header to LabVIEW file to contain the version of LabVIEW

Display VI version in title bar

Version independent Source Code Saves

When you open a VI which includes add-on libraries and/or toolkits, LabVIEW will detect them and suggest installing for users!

 

This will be helpful if the user does not know much about NI software.

 

Install Suggestion.png

 

 

A LabVIEW application installer generated from App Builder creates multiple folders and files in the folders. It is desirable to have a single file installer so that customers see only 1 file to install.

All the other Build Specification has already this function available. Why not the Installer and the ZIP File.

 

Dany

Flatpak is a distribution-agnostic package manager, as long as Flatpak is installed on the system, the same Flatpak package can be installed on any distro. A Flatpak package contains not only the application, but the libraries needed to run it.

 

So, if NI creates flatpak package with LV and all of its dependencies, then we would have a LV that it's able to run in any distro! Without to having the hassle to manually support every major distro or (like at the moment) only supporting a few of them.

Hi, i wanted to suggest the creation of a separate utility software that would convert a VI from any version to any other version. This would save people a lot of time by not waiting to get it converted from their respective threads. Also it would serve for more people to able to reply on the forum(me included since i am using LabVIEW 8.6 and most of the posts contain VIs made in 2009 and 2010 even though most of the time the same functions are avalable in 8.6 😞 ).

 

 

PS: Sorry, got no pictures

 

It would be very nice if we could tell the installer script to synchronize its version number with the version number of a specific executable.

 

12-29-2009 2-38-53 PM.png

 

Additionally, it would be very nice to have this version information (once they are synchronized) displayed on the installer wizard (for instance in the title window or on the wizard first page).

 

PJM

With Application Builder installers there is no way to flag a file as a 'shared' component in the build specification.  This feature is used in MSI installation when files are shared or common among multiple product installers; for example, the files located in \National Instruments\Shared are common dependencies for NI products or in LabVIEW-built EXEs this could be a shared dependency between two applications, like a DLL.  Currently, if two product installers built in Application Builder install the same file, when either of these products is later removed the shared dependency goes with it and the second product is broken!

 

Some good news is you can use MSI editors like InstallShield to edit the MSI after creating it with Application Builder in order to enable a tag/setting for your shared files:


InstallShield.png

 

There are also open source MSI editors available, like Inst Edit, with similar options for tagging files as shared components.

 

What can be done in Application Builder?

Could an option be added to 'Source File Settings' to tag files as 'Shared' so a third-party MSI editor is no longer necessary?

AppBuilder.png

<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? 🙂

/Y

I would like to include arguments for any/all shortcuts from the installer. Currently you can build a labview installer to put shortcuts on desktop and to the "Program Files" menu. But there is no option to include arguments. See attached image of how it would look in labview.

 

InstallerShortcutArguments.png

 

This would allow for the installer application to include file path arguments into any executable. Example: You want to include a tftp server application for the installer and embed the tftp path in the shortcut.

 

It could also be usefull to run the same labview app with many startup arguments. Like if you have a debug mode and normal mode. If you want to include both options on the desktop you could use a -debug as the argument. And include it in the shortcut from the installer. Both shortcuts would point to <application> but one would also say "<application> -debug"

 

Thanks.

 

-Corey

For LabVIEW users,

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

Delete option in Context Menu.png

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...:smileyhappy: He! He! He!

Hi,

 

Wouldn't it be simpler instead of alien and directory manual setup (with still incompatibilities) that NI compile Labview 2020 SP1 into a .deb package? As:

- the Debian/Ubuntu user community is huge,

- CentOS has been abandonned with end of support on 12/31/2021, replaced by some kind of an "experimental" linux

- RedHat was acquired by $IBM$,

- Suse on the other hand is tedious.

 

Thank you NI!

Christian

Private NI customer since LV 1.1

When you run the LabVIEW Platform DVD, the default setting is that LabVIEW gets installed and nothing else. You can then go pick and choose what modules and toolkits to install. I like this default because I usually only want to install LabVIEW and a few other modules and toolkits. It is faster for me to select the few modules that I want to install rather than unchecking all of the modules I don't want to install.

 

When you run the Device Drivers DVD, it tries to guess what drivers you want installed based on the software you already have installed. However, it usually wants to install more drivers than I want it to install. It is a hassle to go through the driver list and unclick the drivers I don't want to install because most of them have dependencies that you have to unclick first. 

 

Idea: Their should be a button on the Device Drivers installation screen to unselect all of the drivers (see image below). I don't think the Device Drivers DVD default should be the same as the Platform DVD; a lot of new users won't know what drivers they need and installing all of the recommended drivers is a safe bet. However, many users do know what drivers they want and it saves time and hard drive space to only install the necessary drivers. Adding an "uncheck all" button would make this process faster and less frustrating.

 

device drivers.png

Add an "Uncheck All" button!

If you are going to call it a developer suite, put the developer tools in it. The following toolkits need to be added:

Of course this will increase the cost of the developer suite. I find it easier to convince my boss to approve a cost increase versus purchasing a new toolkit.

 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!