Driver and VI Library Development Guidelines

As the NI Tools Network continues to grow, it is more important to distinguish which of the more than 400 available Add-ons meets a level of compatibility that helps to ensure developer success. This development guidelines document provides the Add-on developer guidance on how to prepare a product that is compatible with LabVIEW and identifies requirements which must be met for the Add-on to be eligible for the Compatible with LabVIEW Program and use the "Compatible with LabVIEW" logo.*

When you follow these guidelines, developers using your "Compatible with LabVIEW" Add-on can be assured that the driver, VI library, or utility will meet the function, style, and documentation they expect from native Add-ons for LabVIEW. As a "Compatible with LabVIEW" Add-on, your product can get better visibility on the LabVIEW Tools Network and you can gain access to the "Compatible with LabVIEW" logo and special promotional material.* 

The requirements within the Application for the Compatible with LabVIEW Program are derived from these guidelines. An Add-on must meet all of the requirements in order to be eligible for consideration for the Compatible with LabVIEW Program and use of the “Compatible with LabVIEW” logo, and must continue to meet all of the requirements with respect to each new version of LabVIEW software released by NI in order to remain in the Compatible with LabVIEW Program and continue to use the “Compatible with LabVIEW” logo. Guidelines which are program requirements are designated by this logo, text, and a summary of the requirements:

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

To interface external software or hardware with LabVIEW, you can develop drivers and VI libraries in LabVIEW or create a DLL in another language and call it from LabVIEW.

Use LabVIEW as much as possible for API development to maximize transparency for the end user and minimize your development time by avoiding working in multiple languages.

1.1. Using the LabVIEW Style Guide

Follow the LabVIEW Style Guide, chapter 6 in the LabVIEW Development Guidelines, that describes detailed steps to help ensure your driver or VI Library is functional and easy to use. Below are a few key sections taken from the manual that you should implement in your Add-on.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD1:  VIs conform with LabVIEW Style Guide.

1.1.1. General VI Formatting

It is essential that your Add-on looks, feels, and behaves like other typical Add-ons for LabVIEW. That way, developers spend less time learning how to use your tool and more time applying it to their applications.

Organize VIs in a hierarchical directory with easily accessible top-level VIs and subVIs in subdirectories and mark your top-level VIs as such within the LLB. Give VIs meaningful names without special characters, and use standard extensions so the operating system can distinguish files.

Substantial documentation increases ease of use. Include a VI description and your name and/or company name in the VI Description on the Documentation page of the VI Properties dialog box. If your API requires a separate help file, you can include that in the VI Description as well.

Load and test VIs on multiple platforms, making sure labels fit and window size and position are correct. Avoid using platform-specific VIs if the VIs need to run on multiple platforms.

1.1.2. Front Panel

The front panels of your VIs are the primary interaction interface for developers using your API. Making sure they are easy to navigate and use adds to the effectiveness of your API.

Give controls meaningful names. Use consistent capitalization. Check for consistent placement of control names. Also, use standard, consistent fonts – application, system, and dialog – throughout all front panels.

Write descriptions for controls and indicators, including array, cluster, and refnum elements. Remember that you might need to change the description if you copy the control. Create tip strips for front panel items so users have an easy way to understand the functionality of controls on user interface VIs.

Arrange controls logically. For user interface VIs, put the most important controls in the most prominent positions. For subVIs, put inputs on the left and outputs on the right and follow connector pane terminals. Arrange controls attractively, using the Align Objects and the Distribute Objects pull-down menus. Use color logically and sparingly, if at all. Make sure that all the controls on the front panel are of the same style. For example, do not use both classic and 3D controls on the front panel.

1.1.3. Block Diagram

Developers turn to your block diagrams to understand your code and to customize based on their applications. Applying the formatting standards found in standard LabVIEW APIs increases your API’s function.

Avoid creating extremely large block diagrams. Limit the scrolling necessary to see the entire block diagram to one direction.

Label controls, important functions, constants, Property Nodes, local variables, global variables, and structures. Add comments. Use object labels instead of free labels where applicable and scrollable string constants for long comments. Use standard, consistent font conventions throughout.

Flow data from left to right. Wires enter from the left and exit to the right. Label long wires with small free labels with white backgrounds and do not wire behind objects.

Use error in and error out clusters in all subVIs and make sure the program can deal with error conditions and invalid values.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD2:  VIs include block diagrams.

1.1.4. VI Icons

The icon represents the VI on a palette and a block diagram. When subVIs have well-designed icons, developers can better understand a subVI without the need for excessive documentation.

Create a meaningful icon for every VI. The LabVIEW libraries are full of well-designed icons that try to show the functionality of the underlying program; use them as prototypes where applicable. When you do not have a picture, text is acceptable. If you localize the application, make sure you also localize the text on the icon.

Do not use colloquialisms when making an icon. Colloquialisms are difficult to translate. Developers whose native language is not English may not understand what the icon does from a picture that does not translate well. For example, do not represent a data-logging VI with a picture of a tree branch or a lumberjack.

Create a unified icon style for related VIs. This helps developers visually understand which subVI calls are associated with the top-level VI. 

1.1.5. Connector Pane

A connector pane is the set of terminals that correspond to the controls and indicators of a VI. Always select a connector pane pattern with extra terminals. Unforeseen additions to the VI may require more terminals. Changing patterns requires relinking to the subVI in all calling VIs and may result in wiring incompatibilities.

Choose the same connector pane pattern for related VIs. Wire related inputs and outputs on opposite terminals so that references, taskIDs, error clusters, and other common terminals line up correctly. Wire inputs on the left and outputs on the right to follow the standard left-to-right data flow.

Try to choose only connector pane patterns with 16 or fewer terminals. While patterns with more terminals might seem useful, they are very difficult to wire. If you need to pass more data, use clusters. Use the Required, Recommended, Optional setting for every terminal to prevent developers from forgetting to wire subVI connections.

Complete the following steps to set a terminal to required, recommended, or optional.

1. Right-click a terminal in the connector pane and select This Connection Is from the shortcut menu.

2. A checkmark indicates the terminal setting. Select Required, Recommended, or Optional.

Include error in and error out clusters on all subVIs, even if the subVI does not process errors. Error in and error out clusters are helpful for controlling execution flow. If a subVI has an incoming error, you can use a Case structure to send the error through the VI without executing any of the subVI code.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD3:  VIs support error handling.

Most native LabVIEW VIs use the 4-2-2-4 connector pane and always use the lower left and lower right connectors for error in and error out, respectively.

(Figure 1. picture of connector pane with error in and error out arrowed -- add caption)

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD4:  VIs use consistent connector pane layout.

1.1.6. Documentation

Document your driver or VI library extensively to increase usability and overall customer experience. Focus your documentation effort on these three areas: Tip Strips, Context Help, and help files.

Tip Strips are the text windows that appear near your cursor when you hover over a subVI's inputs and outputs. Use a simple, descriptive title for your subVI inputs and outputs so that the developer can easily understand what each connection represents.

The Context Help  window displays basic information about LabVIEW objects when you move the cursor over each object. Objects with context help information include VIs, functions, constants, structures, palettes, properties, methods, events, and dialog box components. Information you include in the “VI Description” text field in the Documentation section of VI Properties (File>>VI Properties>>Documentation ) appears in the Context Help window when a developer hovers above your VI while the Context Help function is activated.

Figure 2. Context Help for NI DAQmx Read.vi, LabVIEW 8.20

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD5:  VIs have Control and Indicator descriptions.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.
 
 

- RD6:  VIs include adequate documentation on using VIs.

You can link your help files to your VIs in LabVIEW or you can include them separately. With the “Help Path” text field in the Documentation section of the VI Properties menu (File>>VI Properties>>Documentation ), you can provide a path to external help files.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD7:  VIs include external help file explaining Add-on use.

1.2. Using External DLLs
Use LabVIEW as much as possible in your API development and refrain from using DLLs unless necessary, so that the developer can access the full functionality of your code. If you need to import DLLs into your LabVIEW driver or VI library, use the DLL Import Wizard as a starting point for calling DLLs. 

1.3. Developing Your Own Error Codes
It is crucial that you develop error codes for your API that address common misuse and data entry mistakes. Thorough user testing helps determine potential error scenarios. Refer to Defining Customer Error Codes for directions on creating necessary error codes. The Wizard is located in the menu at Tools >> Advanced >> Edit Error Codes.

1.4. Testing
The NI LabVIEW VI Analyzer Toolkit is an Add-on product for LabVIEW intended to help developers improve the overall quality and reliability of their LabVIEW code. Through an interactive wizard, you can configure more than 60 different tests that analyze VIs to identify performance, style, and maintenance issues. Using the LabVIEW VI Analyzer Toolkit, you can quickly find stylistic and functional problems within your code and consistently enforce recommended LabVIEW programming practices within teams of developers. Due to the utility of the LabVIEW VI Analyzer as a debugging tool, you may find that regular LabVIEW VI Analyzer Toolkit use improves all aspects of your LabVIEW applications.

This toolkit is included with the NI Developer Suite, or you can purchase it separately. Refer to the LabVIEW VI Analyzer Toolkit tutorial for more information about the LabVIEW VI Analyzer Toolkit.

2.1. Project Libraries (LabVIEW 8 and Higher)

Figure 3. LabVIEW Project Containing a Project Library

NI recommends using project libraries for VI libraries. By grouping your VIs within a project library as part of a LabVIEW Project, your VIs share a common namespace that helps avoid naming collisions in memory. For example, consider a large application that includes two different instrument drivers, InstrDriver1 and InstrDriver2, whose VIs are respectively organized in project libraries called InstrDriver1.lvlib and InstrDriver2.lvlib. Assume that each of the instrument drivers contains a unique VI called Initialize.vi.

The names that LabVIEW uses for these VIs would be InstrDriver1.lvlib:Initialize.vi and InstrDriver2.lvlib:Initialize.vi.

You can then call both of these VIs as subVIs from the same top-level VI without any problems. Note that in previous versions of LabVIEW this was not possible because LabVIEW identifies VIs by their filenames and both VIs are named Initialize.vi.

Use caution in how you name VIs outside of project libraries. For example, if you used names such as “Parser.vi,” “Analyze Waveform.vi,” “Handle Errors.vi,” or “Get Data.vi,” it is almost certain this name is the same as another VI that is shipped with LabVIEW or another add-on. Use VI names that are descriptive and unique, even adding a prefix to the beginning of each VI within your driver or VI library. For example:

·         top-level VIs (appearing in the palette and documented): two or three letters, all capitalized, plus space, then name of the VI (for example, “SML ,” “SVT ,” “OAT ”)

·         subVIs (not intended to be used by customers): two or three letters, all lower case, plus underscore, then name of the subVI (for example, “sml_,” “sv_,” “svs_”)

2.1.1. Public and Private Access Settings

Configure access settings for items and folders that a LabVIEW project library owns as public or private to protect against future changes to the library that could negatively impact your code. If you set an item as private and lock the project library, the item is not visible in the project library or in palettes. You cannot use a private VI as a subVI in other VIs or applications that the project library does not own, even if the project library is unlocked.

Determine which items in the project library you want to set as public and which as private. Public items might include palette VIs, XControls, instrument drivers, and other tools you want developers to find and use. Private items might include support VIs, copyrighted files, or items you might want to edit later without taking the risk of breaking developers’ code.

Including example VIs increases developer understanding of your driver or VI library’s functionality. A good example includes the use of many of your VIs and detailed documentation in the main VI of the program’s behavior. Refer to any of the shipping examples in LabVIEW (Help>>Find Examples... ) for more information. 

Include examples based on your driver or VI library in the LabVIEW Example Finder. Please refer to the Preparing Example VIs to Appear in the NI Example Finder document on how to add example programs you create to the LabVIEW Example Finder.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD8:  VIs include example VIs that demonstrate how to use Add-on.

Create user documentation that explains how developers can use your product. As mentioned in previous sections, effective documentation greatly increases user satisfaction and decreases the amount of time you spend supporting your code. You should review your documentation for accuracy each time you update or otherwise revise your driver or VI library.

There are three principal areas on which to focus your documentation efforts: tip strips, Context Help window, and help files.

Tip strips are the text windows that appear near your cursor when your cursor hovers over a VI or function in LabVIEW. The tip strip text is the name of the control or indicator you label within the subVI.

The Context Help window, when activated on the menu bar of a VI, is a large window that appears when your cursor hovers their mouse over any object. Standard LabVIEW objects have default information already provided. You can add descriptions and documentation for your VIs in the “VI Description” portion of the Documentation section of the VI Properties window (File>>VI Properties>>Documentation>>VI Description ).

You can link Help files to your VIs in LabVIEW or you can include them separately. Through the Documentation section of the VI Properties, you can provide a path to external help files (File>>VI Properties>>Documentation>>Help path ).

Finally, include the versions of LabVIEW that you have used to test your product and the minimum version to install.

Simply save your driver or VI library to the user.lib directory (Program Files>>National Instruments>>LabVIEW 8.2>>user.lib), and your VIs automatically appear in the User Libraries Palette on the LabVIEW Functions Palette. If you want to create a subfolder hierarchy just for your driver or VI library, use Creating LLBs to create the necessary file structure and save that LLB in the user.lib directory.

Use the user.lib instead of vi.lib or instr.lib directories. The user.lib file structure is designed to house custom VIs, and placing your VIs there ensures that any future version modifications to the core vi.lib and instr.lib files do not affect your driver or VI library.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD9:  VIs install to an organized directory not within vi.lib or instr.lib directories.

Lay out the different objects of your API on the palette in the same format as standard LabVIEW Palettes. That includes placing your top-level and Express VIs on the top line of palette items and lower-level or subVIs below them. Subfolders and utility tools go on the lowest lines of the palette. The File I/O palette from LabVIEW is a good example of palette organization.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD10:  VIs are accessible through an organized palette.

6.1. Licensing

Refer to the Distribution Requirements section of the applicable NI Software License Agreement for information on complying with licensing obligations with respect to distributed copies of your Add-on and activation of accompanying LabVIEW software.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD11:  Driver/VI Library complies with licensing and activation obligations.

6.2. Installation

Save your driver or VI library in the earliest version of LabVIEW supported by your add-on to test backward compatibility across the range of LabVIEW versions your add-on supports.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD12:  VIs are saved in the earliest LabVIEW version you cite as supported.

The best method for packaging your add-on for distribution to customers is to create a source distribution from within a LabVIEW Project.

Figure 4. Create a source distribution to package your add-on for distribution.

Within the “Distribution Settings” tab, select “custom” under Packaging Options and check the “Destination is LLB” box. The LLB you create includes all VIs in the LabVIEW Project.

Figure 5. The LLB you create includes all VIs in the LabVIEW Project.

Developers then are able to install the LLB to the user.lib directory, and the driver or VI library appears in the User Libraries Palette on the Functions Palette in LabVIEW. Marking VIs as Top-Level VIs in an LLB provides instructions on how to organize your LLB so that the right VIs appear correctly in the new palette.

As mentioned previously, it is crucial for developer success that you include clear installation instructions that feature screenshots of the process. 

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD13:  VIs include clear installation instructions.

6.3. Mass Compiling

Your installation instructions should recommend that the developer mass compile the driver or VI library after installing it in the Functions Palette. This ensures that the new VIs link appropriately to necessary subVIs. You must test to be sure that your Add-on compiles in the most recent version of LabVIEW.

This guideline is a requirement for "Compatible with LabVIEW" Add-ons.

- RD14:  VIs are mass compiled into the latest version of LabVIEW.

* Allowance of participation in the Compatible with LabVIEW program, granting  permission to use the “Compatible with LabVIEW” logo, and listing an Add-on on the LabVIEW Tools Network, are each at NI’s sole discretion. NI reserves the right to refuse to permit an applicant to participate in the program and/or  use the logo, and to terminate such participation and use, even if the submitted Add-on meets all of the requirements for the program.  NI also reserves the right to refuse to list any Add-on on the LabVIEW Tools Network,  to refuse to mark any Add-on  as “Compatible with  LabVIEW”, and to remove such listing and marking, even if the Add-on meets all of the requirements for such listing and marking. Use of the “Compatible with LabVIEW” logo and participation in the Compatible with LabVIEW Program are in any event subject to and conditioned upon the applicant and NI  entering into a “Compatible with LabVIEW” Logo License and Program Participation Agreement acceptable to NI.   Neither this document, nor provision of a copy, form, draft or sample of such an agreement, is an agreement or offer by NI or otherwise binding on NI.