NI LabVIEW Development for Team-Based Projects

Publish Date: Oct 02, 2015 | 18 Ratings | 3.39 out of 5 | Print | Submit your review


It is rare for an engineer to work alone when developing a large, complex LabVIEW application. For the vast majority of applications, a team of developers or engineers work together on the same set of code. However, without proper investment in infrastructure and planning, group development can introduce several pitfalls and inefficiencies.

The following document discusses the challenges and recommendations for improving team-based development in LabVIEW.

Table of Contents

  1. Providing Centralized Access to Code and Tracking Code Changes
  2. Identifying and Merging Code Changes
  3. Sharing Code Across Development Teams
  4. Implementing Common Development Standards
  5. Additional Resources

1. Providing Centralized Access to Code and Tracking Code Changes

One of the biggest challenges faced by developers who migrate from creating applications independently to doing so as part of the team is defining a central location to store code. A central location is necessary to clearly define what code developers should use for development, as well as provide an area where developers can store code updates where other developers can find it.

A second challenge developers face when creating applications as part of a team is coordinating code modifications. As developers edit existing code and create additional code, they must communicate these changes to other developers and control access to the code that developers are modifying.

Finally, because of the volume, frequency, and distributed nature of changes to code in a team environment, developers face the challenge of understanding the reason and source of code changes many months after the changes occur.


Use Source Code Control During Development

Source code control provides an efficient and powerful system to store, manage changes to, and document revisions of code. Source code control software maintains a centralized copy of application files. When a developer decides to modify a file, he or she checks out the file from the source control software’s repository to edit it. After the edits are complete, the developer checks in the new version of the file, which becomes part of the master copy of the development project.

Source code also control helps coordinate code modifications by locking out developers from editing code if another developer is currently editing the code. If a developer wants to edit code in parallel with another developer, source code control gives developers to the ability to create new code branches, which can be merged in the future if necessary.

A source code control system also helps developers prove that no modifications have been made to a code base. Source code control systems can show that a particular version of code is being used in an application. If a developer wishes to store LabVIEW code in a source code control system and prove that no changes have been made to the code, then he or she should store a source only version of the VIs in source code control. Source only versions of VIs strip the compiled the object code from a VI and contain only underlying code.  By limiting the VI to its underlying code, changes to the object code generated by modifications to sub VI or calling VI links will not affect the file stored in source code control.

Integrate Source Code Control with the LabVIEW Development Environment

Integrating source code control into a development process can add unnecessary overhead if not done efficiently. The most efficient way to integrate with source code control systems is to do so directly from the development environment. With the LabVIEW development environment, users can interact with industry-standard source control providers such as Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS Version Manager, MKS Source Integrity and free, open-source software such as CVS.

Figure 1. The LabVIEW Development Environment lets users check files in and out from source code control.

To learn how to integrate LabVIEW with a source code control provider, read the white paper on Source Code Control and Group Development Practices in LabVIEW for Advanced Configuration Management Tasks.

Documenting Changes to VIs in Source Code Control

Most source code control providers allow developers to attach a description of the changes made to a file when it is checked into source code control. By documenting and describing changes to code, developers can more easily understand modifications and the rationale behind the change. Developers can maintain a revision history for not only LabVIEW VIs, but also any file that has been added to a LabVIEW project. The source code control provider defines the format that revision histories are presented. For example, Figure 2 shows how Perforce displays the changes of a VI.

Figure 2. Perforce displays the revision history of a VI.

Back to Top

2. Identifying and Merging Code Changes

Team-based development often relies on the process of merging a developer’s modifications with a master copy of code. Developers commonly develop in branches of the main code base and must merge their branch back into the main code base. Understanding the differences in code can be challenging, especially for very complex code. In addition, merging changes from one code-base to another can be very time-consuming and error-prone.


Use Graphical Differencing to Identify and Merging to Consolidate Code Changes

The graphical differencing tool in LabVIEW lets developers identify changes in VIs by graphically highlighting the differences between two versions. If a source code control provider is configured, developers can automatically compare the current version loaded in memory with the last version checked into source code control. Developers can launch the graphical differencing feature in the Tools > Source Control menu or by selecting Show Differences from the right-click menu in the Project Explorer. If developers are using a provider that does not support the integration of differencing, they can still run the comparison manually from the tools menu by selecting Compare VIs.

Figure 3. The LabVIEW graphical diffing tool can show changes between different versions of a VI.

In many cases it is not sufficient to just understand the differences between two versions of a VI. Developers must understand the differences between VIs and merge the changes into a new version. With the LabVIEW VI Merge tool, developers can visualize differences in up to three different LabVIEW VIs, identify conflicting changes, and merge the different versions into a single version.

Back to Top

3. Sharing Code Across Development Teams

As an application grows larger, it might become challenging to share and maintain code among teams of developers. Without an in-depth understanding of the complete architecture of an application, developers might not be able to predict the outcome of making a change to a section of code. In addition, applications with monolithic architectures can make it impossible for any of its pieces to be reused in other applications. Finally, even if application components might be reusable, the time necessary to collect and distribute all necessary code might increase development time significantly.


Modularize Applications into Reusable Parts

To facilitate the reuse and sharing of application components, applications should consist of modular pieces, which developers can run and test independently. The modular pieces should provide a public interface for developers to interface with the component in a defined and controlled manner. In addition, the components should be encapsulated to prevent other developers from working with private instead of public interfaces.

Use Project Libraries, Packed Project Libraries, or Source Distributions to Encapsulate Reuse Libraries

Modularized code can be packaged in multiple ways. In LabVIEW, three of the most common ways of sharing or reusing source code are with project libraries, or .lvlib files, packed project libraries, or .lvlibp and source distributions, or .llb files. Depending on the type of application, each of these libraries has its own advantages over the other and makes the sharing of the source code easier.

Modularized code must expose an interface or API for users to operate on the code’s functionality. These APIs expose VIs that can be called by the user, and hide low-level VIs, which perform the expected operations. Developers who wish to give other developers access to the underlying code exposed by the API in addition to the API itself, should use project libraries, or .lvlib files. Project libraries can define a clear public and private interface and provide the library’s code to the user. On the other hand, if developers wish to expose an API, but avoid that any user make changes to the underlying code of the library, then they should use packed project libraries, or .lvlibp, which act similarly to DLLs.

Figure 4. LabVIEW packed project libraries give developers the ability to expose an interface and limit editing to private VIs.

When developing a number of applications for different projects, there are times where some of the same functionality must be used several times. In these situations, it is helpful to be able to port these functions to other development machines easily and to be able to access them when desired. Because these VIs will be moved from project to project and are not dependent on the specific application, an .llb makes a good candidate for housing the VIs.

Use the Package Manager Tools to Collect and Distribute Reuse Libraries

Even if developers divide their application into modular and reusable components it might be challenging for other developers to collect all the necessary dependencies to edit and run the components. Package management tools help developers collect and distribute code and dependencies into packages. These packages can be distributed to other developers, facilitating code sharing. The VI Package Manager (VIPM) is a tool specific to LabVIEW for developing packages.

To learn how to share reuse LabVIEW code, read the white paper on Best Practices for Sharing and Reusing LabVIEW Code.

Back to Top

4. Implementing Common Development Standards

Multiple studies have proven that the majority of the development cost of an application is accrued after the application is developed. Code must be improved, expanded, and maintained. In most cases, the code that developers must work on was not developed by them. Although allowing each developer to follow his or her development idiosyncrasies might accelerate the development of the application, the multiple development standards found in application increases the difficulty of maintaining the application in the long term. Therefore, common development standards when working in team-based development can reduce development costs.


Create Common Development Standards Early in Development

There is no guaranteed solution for defining common development standards for LabVIEW in an organization. How applications should be developed depends on the level of quality, development timeline, and amount of reuse required of the application. On the other hand, a good starting point can be the LabVIEW Style Guide, which is part of the LabVIEW Development Guidelines document. Whichever standards a team agrees on, they should be implemented as early and consistently as possible to facilitate code maintenance in the future.

Enforce Standards Throughout Development

The implementation of common development standards requires discipline and enforcement throughout the development process. One of the most effective methods to enforce common development standards is to implement code reviews that involve the evaluation of the code by a peer. Code reviews can also be automated with tools such as the LabVIEW VI Analyzer Toolkit, which runs preconfigured and custom tests on LabVIEW VIs to guarantee compliance with a development standard.

To learn how to use the LabVIEW VI Analyzer Toolkit to automate code reviews, read the white paper on the LabVIEW VI Analyzer Toolkit Overview.

Back to Top

5. Additional Resources

Software Engineering with LabVIEW

Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No