LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I often need to build applications and installers that include VIs or .LLBs that have been built earlier on...but this is a major pain because as long as LabVIEW recognises the file type it will try to link the VI or VIs in the library to the other VIs in the project, it finds conflicts etc. There are ways to come around it yes, but not very elegant ones.

Basically what I want is for projects to be able to treat VIs and LLB files as non-LabVIEW files. Just like you can include a text file, a JPG picture or other files in your project and installers I want it to be simple to add "completed" LabVIEW files.

One solution could be to have another type of project folder. We have auto-populating folders...perhaps we could have a folder for pre-compiled / to be treated as external sources folder...? In most cases for me LabVIEW could just see that the file does not contain any source code and then treat it as a "dead" file..or at least give you the option to do so (if there is a potential conflict).

Living in the dark ages I do not have web access on my LV development PCs and so have to go to www.ni.com/activate to turn on LV after every update/install. If I am lucky I can sit my LV machine beside my web PC and type in the computer ID code and vice-versa with the resulting authorization code. If I am unlucky bits of paper, pens and walking become involved. Having to authorise on each PC is reasonable but if I need to authorize more than one product e.g. LV and Application Builder (I have the Pro version) then not only do I have to licence 2 things but I have to enter ALL the data twice - a simple 'activate another product' button at the end of the activation pages (with data like pc id and licence number and name etc retained) would make life easier. My appologies if there is one already - but if there is it needs to be more obvious.

View All (1)

The right side of LabVIEW Getting Started window presents links to resources can help the LabVIEW user to be successful in its application development.

With LabVIEW2009 links that update dynamically has been added under Latest from ni.com. I found very useful to be updated on LabVIEW News directly from the Getting Started window but I would like to see the news published by the local branch.

If the link is localized, I can be updated on new events organized in my Country, on new products release and announcements written in my native language.

View All (2)

The Registry Settings within the Build Spec from an installer is using fixed values only.

It would be nice to have somthing like varaibles that contain the information that are entered on the page
"Productinformation" in the settings window from the installer.

Productname -> %productname

Productversion -> %productversion

User selected Path for installation -> %installdir

This would allow something like this:

The values {%productversion} etc. will be replaced during the setup with the real values. The %installdir contain

the selected installation dir from the user.

Allowing proxy settings for LV

At my current work place we use proxy servers as an internet connection. With LabVIEW it makes it difficult not only while the NI software is being installed (to check for updates, connect with server for veryfication etc) but also during typical work it makes troubles with finding examples and drivers from a development enviroment.

I would suggest adding some advenced internet connection options for proxy settings etc.

Another little thing with a company computers is that, even when installing NI software on a D drive it still installs some example software on C:. It makes problem when your IT limited your C drive for absolute minimum, because with huge amount of NI software the amound of "additional" data is getting bigger and bigger.

Regards,

PacHOOk

LabVIEW Compatibility Modes

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

View All (3)

Our facility runs only one version of labview at a time and that majority of time for installing a new version is spent removing the old version. A check box on the installer to remove or update the previous version would be a great addition. In recognizing that several companies must support multiple versions of labview removing the previous version should just be an option, not required. 2nd having the option to select all toolkits and addons to install from the first disk then just a prompt for the other install disks as needed would really speed up the install process as well.

This is not my idea, but I did not see it here and it is a good one so here goes. A lot of people used to deliver chunks of code as DLLs or EXEs but not use them as DLLs or EXEs. Instead they would use them like LLBs and make VI server calls to them. This was possible because when it came right down to it, these DLLs and EXEs were LLBs with extra stuff. This changed after 8.2. No worries because there is the source distribution. Except that the the source distribution is exactly what it sounds like. It is a copy of the source meant to be sent to some other developer. It does not do any of the compile time processing, such as remove conditionally disabled code, that the DLL and EXE builds do. Delivering drivers and other chunks of code as LLBs is a convenient way to distribute patches and so on. But if any of your code has conditional disables, it won't work. The suggestion is to allow the option in the Build menu to remove conditionally disabled code from the source distribution. Here is a thread that discusses the issue. http://forums.ni.com/t5/LabVIEW/conditional-disable-no-longer-works/m-p/1109759

View All (2)

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)

Does this idea need any more explanation? If someone swipes the box out of a mail slot at work and installs it at home, that becomes the "at home" installation.

I realize Ideas with pictures do better, so here's a Golden Retriever puppy...

Message Edited by Broken Arrow on 06-11-2010 07:40 AM

Remake For Loop

View All (3)

View All (2)

When the Developer Suite DVD binder arrives, the first thing I do is find a black Sharpie, cross out the name (e.g. 2010) on the binder label, and write the version of the software it contains (e.g. 2009 SP1).

Rarely if ever do I care which year the DVD binder shipped to me -- all I care about is the version of the software (the most important being LabVIEW) it contains.

Now that LabVIEW and most other NI software products are on an annual release cycle and named according to the year and service pack, I would love it if the Dev Suite binders were named the same way.

View All (4)

Cleaner Upgrades

NI flavor of Linux

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)

Support for Ubuntu Linux

View All (5)

LabVIEW Idea Exchange

Projects should be able to ignore that a file is a VI or .llb

Activation web page should loop for multiple activations

LabVIEW News Localized for my Country

Application Builder, Installer Registry -> allow variables like %productversion, %productname, %installdir in the Registry

Allowing proxy settings for LV

LabVIEW Compatibility Modes

Add header to LabVIEW file to contain the version of LabVIEW.

Reduce Steps to install Labview and simplify installer options

Optionally remove conditionally disabled cases from source distributions

Create .exe file independent to LV runtime engine

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

Stop Putting The SERIAL NUMBER right on the BOX!

Remake For Loop

Installer for Labview Web server browser ... light Labview Web client installer

Fewer steps when downloading and installing LabVIEW from web

Developer Suite release names should be software year and service pack (e.g. 2009 SP1) instead of DVD shipment year (e.g. 2010 DSx)

Make App.Version return the application version, not the Run-Time version

Cleaner Upgrades

NI flavor of Linux

Support for Ubuntu Linux