Search Articles
Recent Articles
LAVA Code on LabVIEW Tools Network
Requirements and Recommendations
Sep 02 2011 12:55 PM |
jgcode
in LAVA Code on LabVIEW Tools Network
This Article outlines the Requirements and Recommendations for publishing code through LAVA onto the LabVIEW Tools Network. My Package is used as an example in throughout this 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
Read story → 4 comments




Guide for LAVA Package Building in VIPM
Oct 25 2011 11:40 PM |
jgcode
in LAVA Code on LabVIEW Tools Network
This article is a guide on how to build a package in VIPM to meet the requirements of publishing under LAVA on the LabVIEW Tools Network.
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:
LAVA Test Package is available for download here:
lava_lib_lava_test_package-1.0.0.6.vip 8.8K
189 downloads
(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.
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.
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.
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.

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.
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).
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.
When the user of your package downloads and installs it, VIPM will automatically install the dependencies if they are not already installed, for example:

Licensing & Activation
Currently not used.
Install Requirements
Set the installation requirements for your package.
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.
Custom Actions
Set these if needed.
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.
Once your package is built and installed it will appear in LabVIEW as follows:
Controls Palette

Functions Palette
Read story → 0 comments




Team LAVA Logo
Sep 19 2011 04:45 PM |
jgcode
in LAVA Code on LabVIEW Tools Network

Attached are various formats.
Team LAVA logo.zip 1.03MB
185 downloads
Read story → 0 comments








