I’m thinking of submitting my SQLite package in the CR to the tools network.  Is “Team LAVA” still active?  

— James

currently iam using some third party driver vi's in one of my application.

My question is during the time of creating installer how to include all those third party driver vi's in the main project.

Generally the default path for the driver vi's is "C:\Program Files\National Instruments\LabVIEW 2010\instr.lib" and how to set this deafult path location for those driver vi's during the time of creating the installer.

Thanks and regards

Sambaiah Gunakala

...

View the full article

Link to the blog post:

LAVA Code on LabVIEW Tools Network

https://decibel.ni.com/content/groups/labview-add-on-dev-center/blog/2012/02/03/lava-code-on-labview-tools-network

Just fire up your copy of VIPM to download it straight from the...

View the full article

As you may know in order to have a toolkit placed on the LabVIEW Tools Network it has to pass Compatible With LabVIEW certification. One of the requirements for the Compatible With LabVIEW program is that tools may not be located on the top palette, but should exist within one of the existing top-level categories such as Programming, Measurement I/O, Data Communication, etc.

The reason behind this requirement is that the LabVIEW Palette can get quite bloated when you have many toolkits/modules installed. With just the full Developer Suite installed, there are over 20 top level palettes. Adding third party tools to this list will very easily bring the functions palette to grow off of the screen for a standard 1024x768 monitor. The secondary reason behind this is that this layout will help users find the functions more easy that will help them. For example if the user is looking for some data communication protocol, they are more likely to look in the "Data Communication" palette then in a sub-palette called "My Data Protocol" under a top level "DavidSoft Inc".

I wanted to point this out so as you all start creating their toolkit for submission to Team LAVA or the LabVIEW Tools Network, you can take this into consideration ahead of time. However, with many things in our program, nothing is black and white. If there are special cases in which a toolkit especially should be on the top level, we will consider letting it go as such. One of these cases is OpenG. Since OpenG has a long-standing reputation and is known to be found on the Top level, it would be more hurtful than beneficial to require it moved to the Programming palette.

If anyone has suggestions or ideas of other corner cases that would benefit from this top level location, or have comments or opinions for or against this policy, please feel free to bring them up here for debate/discussion.

--David Out

View the full article

View the full article

You can build packages in VIPM Community Edition (which is free). Alternatively you can use OpenG Package Builder - whatever is preferred.

This guide is aimed to help developers new to package building and for everyone to see what the requirements look like in VIPM and is presented as a walk-through of each screen in the VI Package Builder UI.

An example package named LAVA Test Package is used for all screenshots:

Download attachment: Package Information.png

LAVA Test Package is available for download here:

Download attachment: lava_lib_lava_test_package-1.0.0.6.vip

(Code is in LabVIEW 2009).

LAVA Palette (external dependency) is avialable for automatic download in VIPM (hosted on LabVIEW Tools Network).

Basic

Build Information

Set the build information for your package here.

Download attachment: Build Information.png

Display Information

Set the Company Name to LAVA; Legal Copyright and Author Name should be your own; Set the License Agreement name (a flexible license is preferred and should be Open Source Initiative approved).

Setting the License Agreement Text File Location requires VIPM Professional, so it is recommended to use only if you have it.

Set the Product Homepage (URL) to the LAVA-CR page of the package (as this is just an example package it cannot be done here) - every package published will have its own LAVA-CR page e.g. Rename LVOOP Labels.

Download attachment: Display Information.png

Palettes

Do not include a Custom Category, this functionality will be provided in a dependent package (see Package Dependencies).

Set the palette Installation Location to Addons\LAVA (minimum requirement).

You can also include as many other palettes as you like that make sense for your package.

Download attachment: Palettes.png

Note: You must have installed the LAVA Palette package first to be able to see and select the LAVA sub-palette in the Palettes in LabVIEW dialog.

Download attachment: Palettes in LabVIEW.png

Destinations

The LAVA installation directory for palette VIs is <vi.lib>\LAVA. Create a sub-folder for your package. The folder structure under this sub-folder is entirely up to you.

Download attachment: Destinations.png

Source File Settings

Namespace your code to be distributed. In this example VIPM old school namespacing is used.

At a minimum, namespacing should reference lava.

Note: If you are importing an existing API over from the LAVA-CR then keeping the existing namespacing for VIs can be considered via discussion).

Download attachment: Source File Settings.png

Advanced

Package Dependencies

List all external package dependencies here. All external package dependencies must be avialable for automatic download from the internet in VIPM (e.g. hosted on VI Package Network or LabVIEW Tools Network).

Tool distributions should minimize external dependencies.

Download attachment: Package Dependencies.png

When the user of your package downloads and installs it, VIPM will automatically install the dependencies if they are not already installed, for example:

Download attachment: Install Dependendies.png

Licensing & Activation

Currently not used.

Download attachment: Licensing and Activation.png

Install Requirements

Set the installation requirements for your package.

Download attachment: Install Requirements.png

Incompatible Packages

If you are converting an existing package (which will have a different name) for publishing under LAVA then that package should added as an incompatible package so that VIPM will uninstall it automatically to avoid any conflicts when the new LAVA package is installed.

Download attachment: Incompatiable Packages.png

Custom Actions

Set these if needed.

Download attachment: Custom Actions.png

Package Filename

The package name should be as per the requirements. This is important as the palettes files generated by VIPM use this name and therefore, by following this convention the LAVA Addons palette will be ordered alphabetically.

Download attachment: Package Filename.png

Once your package is built and installed it will appear in LabVIEW as follows:

Controls Palette

Download attachment: Controls.png

Functions Palette

Download attachment: Functions.png

Click here to view the article

This is the most downloaded file in the LAVA-CR - with 4,235 downloads to date - and will be great to see it published through LAVA on the...

View the full article

Requirements

Installation Type

Code must be distributed as a package (.vip or .ogp). This will mean it is compatible with both the LabVIEW Tools Network and VIPM

Installation Directories

Installation directories have been standardized for the purpose of organisation and avoiding namespace clashes etc.

No package released on LAVA, in the LAVA-CR or elsewhere should install to these locations - only those packages that are approved by LAVA for the LabVIEW Tools Network

Once your package has been accepted, you will own that namespace and can install to other locations (if haven't already) in the future (think of it like a domain) without worry of collisions

Palettes: <vi.lib>\LAVA<\package_name>

Tools: <project>\LAVA\<package_name>

Examples VIs: <examples>\LAVA\<package_name>

Examples .bin3 files: <examples>\exbins

Addons^#: <vi.lib>\addons\_LAVA\<package_name>

^# Not for distributions that contain public VIs (i.e. VIs appear in palette or need to be linked to by end users)

Package and Palette Namespacing

Example package names will be lava_<type>_<my_package>-<version>

Where type = lib for Libraries and type=rsc for Resouces/Tools

E.g. lava_lib_my_package-1.0.0.1.vip

In VIPM the package name is directly related to the palette name

We require packages to be ordered alphabetically in the dynamic palette hence, the above convention must be followed

Additionally, if using OpenG Package Builder, palette name must match the equivalent VIPM name

VI Namespacing

It is recommended that VIs should be namespaced similar to old school VIPM renaming syntax (e.g. __lava_lib_<package_name> however, at a minimum __lava should be used

If a LabVIEW Project Library is used to namespace code instead, then add __lava namespace to the distributed library

Palette Location

Both .ogp and .vip packages that contain palette VIs will link to the LAVA Palette package as a dependency which is published on the LabVIEW Tools Network.

The palette must appear under the Addons\LAVA top level palette however, users may wish to include another palette under the correct programming sub-palette.

The VIPM Custom Category feature is currently not used

Dependencies

Any package dependencies must be also published on the LabVIEW Tools Network (aka external dependencies). Packages (especially Tools) should try to limit all dependencies by building in supporting VIs to the package (aka internal dependencies)

Coding Standards

The code distributed must meet the requirements of being LAVA Certified. Additionally you should follow the LabVIEW Development Guidelines and the standards for the Compatible with LabVIEW level that you ultimately want to achieve

Recommendations

Iconography

We recommend you use any color, glyphs, text etc... for your icons. There is no set theme or icons - we don't want to stifle your creativity!

License

We recommend that you distribute under the most flexible license to aid in end user reuse (e.g. new-BSD license), but there is no licensing requirement - only that you have one

It is recommended that this license is Open Source Initiative approved

Adding a License Agreement file is also recommended (but this requires VIPM Professional)

Premium Membership

It would be helpful if members maintained Premium Member status so they can edit and delete posts etc... to maintain their forum professionally

However, if not, we will open up this functionality for Team LAVA Developers

Folder Naming

Excluding Tools location, it is recommended that the folder name is package_name note: lower case and contains underscores for space

E.g. <LabVIEW>\vi.lib\LAVA\my_package

Click here to view the article

The logo incorporates the LAVA name and logo into a community/team theme.

I love it!

If you want to get...

View the full article

Attached are various formats.

Download attachment: Team LAVA logo.zip

Click here to view the article

LAVA is a facilitator and as such we...

View the full article

View the full article

Top LAVA-CR author François Normandin (aka the man in the kilt) who has a total of 16,951 file downloads, and counting, will be releasing his awesome UI Tools...

View the full article

End users can easily find, browse, buy and download your code all in the one spot on NI's website or through using the...

View the full article

Today I am very excited to announce a new initiative starting on LAVA. LAVA has created a publishing avenue for LAVA developers on the LabVIEW Tools Network (LVTN).

During concept development the code name of this project was Team LAVA (hence where the blog name...

View the full article