LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

It's almost 2014, time to make a state-of-art installer.

I think LabVIEW absolutely needs these features:

create a multi-language installer

make the dialogs translatable, or provide translated dialogs. This work can be done by the community in some weeks.

ability to create a 1 language installer, or multi-language installer (selecting which languages to incorporate).

The bootstrap installer will check the windows language and will load the appropriate strings for the dialogs. If the language is not present, english fallback.

PS: LabVIEW still has the problem of localization and globalization (runtime supports only few languages, built-in error codes are in few languages, no unicode, no easy tool for localization, no support for globalize application with culture-info formatting strings and dates, etc...) but this is matter of another idea.

add features to installer

Suppose you want to make a software made of 3 features (example: core, doc&examples, a plugin), and user can select the full installation (all 3), the custom or the simple installation (only core).

we need the dialog for this, and the ability to assign components to features in authoring

this is all pretty standard stuff nowadays.

create a single file installer with embedded resources, exe or msi.

a single file is easier to download (1 click), we avoid tedious procedures like "make a auto-extracting zip files and run setup when done". A single MSI is a winner in enterprise scenario, where it can be managed better by sys-admins and their software.

update check facilities

so software today is very changing: not only bugs, but according to Agile principles, today developers starts "small", and then proceed with increments and sprints, using tools like git, build servers, repositories, etc...

this is the way software is today.

if you develop software in a waterfall fashion....you are stuck in the 80s-90s, pretty much out of market.

So it is essential to have a built in update, at least an easy stuff.

For example, let developer specify a rss-like file on a server that has information about the latest software, and provide some vis that interact with that.

Don't you want to re-invent the wheel? Port Sparkle on LabVIEW (http://sparkle.andymatuschak.org/).

This would be great for LabVIEW 2014.

I'll come back at august 2014 to verify lol

bye

View All (2)

LabVIEW version alert

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.

include ADCS in Developer Suite

Current versions of Developer suite do not include Autmotive Diagnostic Command Set
in the DVD's for installation onto a host PC, the toolkit has to be downloaded separately which can be difficult to find as it is not referenced on the support pages, for those interested the 1.1.1 release is here:

ADCS 1.1.1

URL:http://joule.ni.com/nidu/cds/view/p/id/3153/lang/en

My thought is that this should become more integrated into the release DVD's as it is a Labview add-on and should be treated the same as all the others.

The addition (in 2013) of the ability to use tags in the directory names of the builders struck me as really useful - normally I build to a ...\MYPROJ\... set of directories (each of the ) then rename ..\MYPROJ\... to ...\MYPROJ x.x.x.x\.... as required. When I read of the ability to use [VersionNumber] and [ProductVersion] tags I thought wahooh - at last an automated mechanism. However when I played with the tags it became clear that each builder (app; Installer; Source) used its own version and did not have access to any other builds' version info. Hence I could not use a single version in all builders. Especially as the Product version is one digit shorter than the others.

Given the principle that the builds now accept tags (akin to macros in my opinion) it would be really useful to have a global version tag (that could be set automatically or manually as present versions) accessible from all builders in a project for use in directory name creation and ---- to go even further ---- to have this global version available from inside the project VIs so I can use it in my window titles and About boxes (I currently use App Info VIs to get a version, date etc to do this).

When developing an unattended installation, creation of the specfile allows customized installation choices.

Due to the number of choices, I have rerun 2013DS1DVD1_ENG\setup.exe /generatespecfile more than once and NI Device Drivers DVD - February 2013\setup.exe several times to add or remove one or two options.

Adding the capability of loading a specfile when launching setup with /generatespecfile filename1 /loadspecfile filename2 would allow the easy editing/modification of the specfile by the installation creator reducing the time necessary to make a custom automated installation of the NI software.

View All (5)

MathScript 64bit

Just found out MathScript Module does not have a 64-bit version yet. I don't know if NI has any timetable to release its 64bit version?

Why do I need a 64bit version? Mainly the memory issue. I have a Matlab code which requires a massive memory allocation. Now I am trying to use the .m code in LabVIEW, but encountered a 'Not Enough Memory' warning message. I think a 64bit version shuold fix this issue, correct?

Besides, 64bit is the future anyway. So in case MathScript Module 64 bit is not even being considered by NI, I would like to suggest it here.

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)

I know that we finally have the Version Conversion board to handle all the "convert this to that" requests that people used to post. Related ideas that have been suggested include 1) a webservice to convert VIs automatically and 2) a specific LabVIEW utility to do the conversion for you.

What I suggest is something a little different and maybe simpler for NI to create. I would like the ability to open a higher version, non-functional VI with the following options:

The ability to see the GUI and block diagram of the VI (maybe as just image files if NI can't handle it otherwise).
A dialog box (or something like that) that gives a summary reason why the VI won't run in your version of LV.
Question mark icons where offending subVIs reside in the block diagram.

I think this would be useful because it would at least let you see how the VI functioned - sometimes that's enough to help you figure out a problem.

View All (2)

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number. For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later. Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions. However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

Changing VI connector panes
Renaming or moving VIs on disk
Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs. Consider the case where I make the following changes to a VI from my toolkit:

	Version 1.0	Version 2.0
VI Path	<userlib>\mytoolkit\CompRes.vi	<vilib>\mytoolkit\Compute Result.vi
Owning Library	none	Mytoolkit.lvlib
Connector Pane

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI. This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

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)

Downloads & Distribution

Once upon a time one could distribute code that was reasonable in size. Now it seems all the runtimes are giga byte size.

It takes far to long to send someone a distribution with all the runtimes. Try uploading 1.7Gig of files...

Can this be reduced at all?

The FPGA compiler needs version 10.4, 11.5, 13.4. This directory is 19.5 Gig! If this directory is included in the backup, it too will take up a great deal of storage resources.

Can this be streamlined?

Rewrite MODBUS library

Set exe to run as admin

I am communicating to parker motor controllers through the Ethernet (parker sample code). Apparently since it is Ethernet based, the code uses socket, where the sockets require admin rights (another discussion about ethernet based and admin rights). In order for my VI to connect to the controller I need to run LabView as an administrator. The problem is I am making this program into an executable for production work.

When I create the executable it will not connect to the controller unless I am running the application as an administrator. As this program will be used in production I want it to be as simple as possible to perform. I don't think there is a simple way to change the environment to run without the need to run application as an admin. Are there any ideas to either change the executable to run as an administrator through the application builder? My plan is to create an installer through the application builder.

Some ideas that I had is to create an installer file and create the executable. Change the privilege level of the executable (properties>compatibility>privilege level>run this program as an administrator). Use a batch file to install drivers and application, then replace application with the one with the elevated privilege level. Another idea I had is use a batch file to do a runas command to run application as an admin. I cannot get either method to work. Does anyone have ideas?

View All (1)

At some point the LabVIEW installer stopped asking who I was and what company I work for during the installation process. Instead, the LabVIEW installer assumes that the "Registered Owner" and "Registered Company" of the Windows installation is what should be used. I'd like it if,

The NI installer stops making this assumption and prompts me for this information.
It was a changeable option in LabVIEW (because changing every registry key doesn't seem to do anything)

View All (3)

When you create an Installer you need to select what is the other build spec that will be used to be installed.

Some time in the resulting files of an EXE build spec we got files that we don't need to be included in the installer.

So I propose to be able to select only the file that need to be installed, not the entire EXE build spec result.

Currently the EXE build spec result files are grayed out and we can only select the entire EXE build spec result files to be included in the installer.

LabVIEW Idea Exchange

Installer: time to make a state-of-art features for a 2014 software.

LabVIEW version alert

include ADCS in Developer Suite

Global version TAG in Build spec directory creation

Unattended installation - specfile edit/modification support

MathScript 64bit

Installer Builder option to require SSE2 support

Ability to view newer/older VIs without converting their version

NI must go to monthly or yearly subscription model for software licenses

Improvements to the "NI Update Service" (shut down the system, when you finish the download.)

Error constant ring should be converted to code when saving in previous version

VI Migration Independent of LabVIEW Version

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

Downloads & Distribution

Remove optical illusions from NI Activation Wizard progress bar of mystery

Rewrite MODBUS library

Set exe to run as admin

Create a single Windows Restore point during installation of NI software and drivers

Change Registered Owner and Registered Company

Installer Build Specification should not depend on the exact result of an EXE build specification