NI LabVIEW VI Analyzer Toolkit Overview

Publish Date: May 30, 2012 | 10 Ratings | 4.10 out of 5 | Print


This article is part of a series on software engineering practices and tools for large application development in LabVIEW.

Click here to view the list of other articles.

Improve the quality and readability of graphical code developed in LabVIEW with the LabVIEW VI Analyzer Toolkit. Configure over 60 tests for automated code review and static code analysis of all VIs in an application.

Use the VI Analyzer to debug and avoid overlooking improper coding techniques that could impact an application’s performance, functionality, or maintainability. Enforce effective programming practices and coding styles within developer teams to ensure code readability and functionality. Overall, use the LabVIEW VI Analyzer Toolkit regularly to develop high-quality, robust LabVIEW applications.

Note: Refer to the LabVIEW Upgrade VI Analyzer Tests for more information about tests that detect potential issues when you upgrade VIs. You do not need the VI Analyzer Toolkit to use the upgrade analyzer tests.

Table of Contents

  1. VI Analyzer Description
  2. Test Overviews
  3. Related Documents

1. VI Analyzer Description

Use the LabVIEW VI Analyzer Toolkit to improve code quality and catch potential problems earlier during development. The LabVIEW VI Analyzer automates code reviews and enables more exhaustive code analysis. Run the toolkit interactively from within the development environment or programmatically use the LabVIEW API. You can customize test parameters with a configuration dialog and save preferences for later use. Once you make your selection, the LabVIEW VI Analyzer Toolkit loads each test into memory, runs the tests on each of your selected VIs, and generates a report listing all the possible improvements or potential problems that the tests identified. 

The LabVIEW VI Analyzer provides the following for each recommendation: 

  • What the tests observed 
  • What the tests discovered about the VI 
  • A link to the VI section tested so you can easily identify the VI area that may need improvements

You can choose the improvements you want to make and then rerun the tests. You also can save your test configuration to run the same tests later. Additionally, you can save the report as either a text file or an HTML document, so you can reopen it at any time and share it with other developers or store it along with the VIs in a source code control utility. 

In the LabVIEW 2010 VI Analyzer Toolkit, you can use the VI Analyzer Test Creator wizard to generate files for your own custom tests that you run in the VI Analyzer to check VIs interactively for style, efficiency, and other aspects of LabVIEW programming. You then can run custom tests on other computers with the LabVIEW development system installed. Refer to Designing a Custom VI Analyzer Test for more information about creating a custom test.

Back to Top

2. Test Overviews

The following section describes the details of each test included with the LabVIEW VI Analyzer.

Block Diagram Test Details

The Block Diagram category of VI Analyzer tests analyzes VI performance and style related to the block diagram. The VI Analyzer groups the block diagram tests into three subcategories: performance, style, and warnings.


The tests in the following list analyze coding conventions that affect VI performance.

  • Arrays and Strings in Loops—Checks loops to see if they contain Build Array or Concatenate Strings functions. Avoid using these functions in loops because each call to them requires a dynamic resizing of the array or string, which can affect memory and processor time. This test does not check Timed Loops.
  • Coercion Dots—Checks the total number of coercion dots on the block diagram and the number of coercion dots on individual wires and compares them to user-specified limits.
  • Enabled Debugging—Checks whether debugging is enabled or disabled. Disabling debugging improves VI performance.
  • Wait in While Loop—Checks While Loops with front panel control terminals for structures or functions other than I/O functions that regulate the speed of the While Loop.
  • Wired Terminals in Subdiagrams—Checks to see if any control or indicator that is wired on the connector pane does not reside within the top-level diagram. To avoid unnecessary memory copies, place control and indicator terminals that are wired on the connector pane on the top-level diagram.


The tests in the following list analyze block diagrams for issues related to LabVIEW style. Refer to the LabVIEW Style Checklist for information about LabVIEW style.

  • Backwards Wires—Checks whether wires flow from left to right.
  • Control Terminal Label Visible—Checks whether labels of block diagram control terminals are visible. To easily identify control terminals on the block diagram, always make labels visible.
  • Control Terminal Wiring—Checks whether wires exit control terminals from the right side and enter indicator terminals on the left side.
  • Sequence Structure Usage—Checks whether the block diagram includes Stacked Sequence structures that contain more than the user-specified maximum number of frames. The test does not check Flat Sequence structures.
  • String Constant Style—Checks the style of string constants on the block diagram. String constants containing no characters fail the test. Replace them with an empty string constant. String constants set to Normal Display that contain only white space—such as spaces, tabs, or line feeds—fail the test. Set the constants to '\' Codes Display to improve block diagram readability.
  • Unused Code—Checks for unnecessary code on the block diagram.
  • Wire Bends—Compares the total number of bends on a wire to a user-specified maximum and compares the length of each wire segment to a user-specified minimum.
  • Wires Under Objects—Checks for wires that run under objects or other wires.


The tests in the following list analyze block diagrams for potential design problems.

  • Adding Array Size Elements—Checks whether the Add Array Elements function connects to the output of the Array Size function to determine the size of a multidimensional array. Wire the Multiply Array Elements function to the size(s) output of the Array Size function to determine whether a multidimensional array is empty.
  • Breakpoint Detection—Checks for breakpoints on the block diagram, including breakpoints on wires, nodes, and subdiagrams.
  • Bundling Duplicate Names—Checks element names in the Bundle By Name and Unbundle By Name functions for duplicates. Duplicate elements can cause confusing and sometimes incorrect block diagram behavior.
  • Error Cluster Wired—Checks that the error output on a block diagram node is wired. You can set the test to ignore VIs with automatic error handling disabled. You also can ignore nodes that usually have unwired error outputs.
  • For Loop Iteration Count—Checks For Loops to ensure that the VI does not use both auto-indexing arrays and the N terminal to govern the number of iterations the For Loop runs. You also can check for multiple auto-indexing arrays governing the iteration count.
  • Globals and Locals—Checks whether a block diagram contains global and local variables.
  • Hidden Objects in Structures—Checks whether any objects in structures are hidden outside the visible bounds of the structure.
  • Hidden Tunnels—Checks tunnels, shift registers, and other structure border elements to see if they overlap each other. Overlapping tunnels can make your block diagram difficult to read. The test currently does not check dynamic event tunnels, tunnels on Timed Loops with frames, or tunnels on Timed Sequence Structures.
  • Indexer Datatype—Checks functions that index array elements and string characters to ensure that signed or unsigned 8-bit or 16-bit integer data types do not index string or array elements. The test ignores functions that use constants for indexing.
  • Pattern Label—Checks whether a file dialog box that uses file patterns specifies a pattern label. The items you can check are the File Dialog Express VI and the browse options on a path control.
  • Reentrant VI Issues—Checks for uninitialized shift registers and non-reentrant subVIs in a reentrant VI. Because reentrant VIs maintain multiple data spaces, unexpected results can occur when using uninitialized shift registers. Additionally, parallelism could be inhibited if the reentrant VI calls non-reentrant subVIs.
  • Typedef Cluster Constants—Checks cluster constants on the block diagram that are linked to type definition controls to determine whether their values match the default value of the type definition control. If a constant has a non-default value and the structure of the type definition changes, the value of the constant might reset. Use the Bundle By Name function to change the value of any elements inside a cluster constant linked to a type definition control.

Documentation Test Details

LabVIEW VI Analyzer tests in the Documentation category check for documentation issues within VIs. The LabVIEW VI Analyzer groups the Documentation tests into the developer and user subcategories.


The tests in the following list ensure that VIs contain documentation that benefits other developers.

  • Comment Usage—Checks whether the block diagram contains a minimum user-specified number of comments. The test also can check whether all subdiagrams of multiframe structures, such as Case, Event, and Sequence structures, contain at least one comment.
  • Label Call Library Nodes—Checks Call Library Function Nodes on the block diagram for labels. You can improve the readability of a VI by using the label of a Call Library Function Node to describe the function you are calling in a shared library. The test fails if a Call Library Function Node has no label or the default label.
  • Revision History—Checks for revision history comments. Clear the revision history when you complete a VI so users cannot see developer comments.


The tests in the following list ensure that VIs contain documentation that benefits users.

  • Spell Check—Spell checks VIs, front panels, and block diagrams.
  • VI Documentation—Checks for text in the VI description, control description, and/or tip strip fields on all controls.

Front Panel Tests

LabVIEW VI Analyzer tests in the Front Panel category analyze front panel design and style. The LabVIEW VI Analyzer groups the Front Panel tests into the subVI and user interface subcategories.


The tests in the following list check the appearance and arrangement of front panel controls on VIs used as subVIs.

  • Array Default Values—Checks charts, graphs, and arrays on a front panel for empty default values. Saving nonempty default values inside charts, graphs, or arrays uses memory unnecessarily. When the VI runs, it overwrites values wired to indicators on the block diagram. If a subVI is using the VI, the VI overwrites values wired to controls connected to the connector pane.
  • Cluster Sized to Fit—Checks that front panel clusters are set to Size to Fit, Arrange Horizontally, or Arrange Vertically. If you do not select one of these autosizing options, cluster objects might not be visible to the user.
  • Control Alignment—Checks that the alignment of controls on the front panel roughly matches the alignment of controls on the connector pane.

User Interface

The tests in the following list analyze user interface design.

  • Clipped Text—Checks that any visible text on the front panel is not cut off. This includes text in control labels, control captions, free labels, and text controls such as strings and paths. The test cannot check the text inside listboxes, tables, tree controls, and tab controls.
  • Dialog Controls—Checks that front panel controls are from the System palette. The test ignores controls that do not have a dialog counterpart.
  • Duplicate Control Labels—Checks that controls on the front panel do not share the same label.
  • Empty List Items—Checks listbox, multicolumn listbox, table, and tree controls to ensure that they are empty. The VI populates the contents of these controls when it runs, so saving a VI with contents in these controls uses memory unnecessarily.
  • Font Usage—Checks that front panel controls, indicators, and free labels use user-specified symbolic fonts, such as application, system, or dialog fonts.
  • Overlapping Controls—Checks that front panel controls do not overlap. The test does not analyze front panel decorations.
  • Panel Size and Position—Checks that a front panel completely resides within the bounds of the screen. The test also checks whether the front panel is larger than the maximum specified width and height. If you are using a multimonitor system, the test fails if the panel does not reside entirely within the bounds of the primary monitor. This test works only on standard, control, and global VIs.
  • Transparent Labels—Checks that free labels, control labels, and control captions all have transparent backgrounds.

General Tests

LabVIEW VI Analyzer tests in the General category analyze aspects of VIs not covered in the Block Diagram, Documentation, or Front Panel categories. The LabVIEW VI Analyzer groups the General tests into three subcategories: file properties, icon and connector pane, and VI properties.

File Properties

The tests in the following list analyze properties of the VI as a file such as filename and size.

  • SubVI and TypeDef Locations—Checks that subVIs and type definitions reside in one of an arbitrary number of user-specified locations (paths and LLBs). If you do not specify a location, the test passes. The test does not check Express VIs on a block diagram.
  • VI Extension—Checks the filename extension. The test fails for any VI that does not have a .vi or .vit extension, or for any custom control that does not have a .ctl or .ctt extension. The test is case insensitive.
  • VI Name—Checks the name of a VI for potentially invalid characters.
  • VI Saved Version—Checks that the VI is saved in the most current version of LabVIEW.
  • VI Size—Compares the file size of a VI to the maximum allowable size you specify.

Icon and Connector Pane

The tests in the following list analyze VI icon and connector pane style issues.

  • Connected Pane Terminals—Checks that control and indicator terminals on the connector pane are wired on the block diagram.
  • Connector Pane Alignment—Checks that inputs wire to connector pane terminals on the left side and that outputs wire to connector pane terminals on the right side.
  • Connector Pane Pattern—Checks that the connector pane pattern, regardless of rotation, matches one of the user-specified connector pane patterns.
  • Default Icon—Checks that VI icons of standard and polymorphic VIs are neither default nor empty.
  • Error Style—Checks that error connections appear in the lower-left and lower-right corners of the connector pane. This part of the test runs only if the connector pane wires a single error in and a single error out terminal. The test also checks whether an error case appears around the contents of the block diagram.
  • Icon Size and Border—Checks that the icon image is 32 × 32 pixels in size and has a solid border. The test does not check the icons of control or global VIs.
  • Polymorphic Terminals—Checks that terminals on all instances of a polymorphic VI appear in the same position on the connector pane of the instance VI. The test does not analyze broken polymorphic VIs.
  • Terminal Connection Type—Checks that controls and indicators on the connector pane that match user-specified names or patterns include the user-specified terminal connection type, such as required, recommended, or optional.
  • Terminal Positions—Checks that controls and indicators connected to a connector pane that match user-specified names or patterns are located in certain positions.

VI Properties

The tests in the following list analyze the overall setup of a VI.

  • Broken VI—Checks for broken VIs.
  • Built Application Compatibility—Checks for properties or methods that are not supported in built applications. Run this test on any VIs you want to build into an application to ensure they function properly.
  • Driver Usage—Checks for subVIs, functions, or property nodes that are part of National Instruments driver software packages. This test does not check for Express VIs that are part of the driver software packages.
  • Platform Portability—Checks for potential problems that might occur when you attempt to port a VI from one operating system to another.
  • Removed Diagram—Checks whether the block diagram is present. Do not remove a block diagram from a VI—you cannot recover it. You can password protect a VI if you do not want users to view the block diagram.
  • Toolkit Usage—Checks whether subVIs are National Instruments toolkit VIs. When you distribute a VI that includes toolkit VIs as subVIs, each computer that runs the VI must have the toolkit VIs installed or the VI does not run correctly.
  • VI Lock State—Checks the lock state of a VI against the user-specified lock state(s).

Back to Top

3. Related Documents



Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No