Blog

Modular LabVIEW architecture

Modular LabVIEW architecture

Many of the LabVIEW applications that DMC develops are based on our internally developed state machine architecture. This architecture has a proven record of allowing us to create flexible, robust, and easy to maintain applications.

One of our clients has a large, multi-PC system built upon this platform which has been in use for a period of years. The architecture allowed several additions over time, including:

  • Periodic temporary or new permanent instruments
  • Data processing updates
  • Integration of additional new ideas and equipment

While the system was able to handle these changes, each addition or removal of functionality required significant programming. The client asked if we could improve the system so that he could easily add or remove new functionality himself. The result was a new modular system that allows unprecedented flexibility.

Design Requirements

We created a set of guiding principles on which to build or development:

  • Each instrument should be contained in its own modular component that must not depend on any other component to function.
  • The user must be able to select modules from a list without having to do additional configuration. In effect, each module should be self-registering.
  • The user must be able to configure settings for all modules in a single place instead of changing multiple modules on multiple computers. Additionally, settings specific to a module should not exist if the module is not in use.
  • Data should be reported, time-aligned, and merged without intervention by the user.
  • The user should be able to specify post-test processing options on a per-test basis.

Major Components

Most of the elements of the system are designed around a self-registering architecture that allows them to be added or removed from operation on a per-test basis. The few key elements that are unique and must run during each test are covered below.

Universal Launchpad

Each computer in the system runs this top level VI. It handles registration of each component on the computer and then registers itself with the master launchpad. The master launchpad is just another instance of this module with a setting that designates it as the primary coordinator for the system. In addition to tracking active modules, the launchpad seamlessly handles computer to computer communications allowing this system to be spread across as many computers as desired with minimal configuration and zero changes to the base code.

Host

The host is the primary user interface for the system. It handles showing options dynamically from any module in the system as well as coordinating the data processing at the end of each test. Where possible, each module performs its own data processing and sends its processed data to the host but there may be special cases where multiple sources are used to create a type of data. This is where the dynamically launched host processing VIs are used. They are selected by the user at run time and allow the client to create small, easy to develop pieces of code that can handle almost any possible desired test.

Facilities Analog DAQ

With the exception of the master time base this VI provides to the system, this is just another VI that collects and reports data according to the standard.

Timing

Timing is handled by a combination of hardware synchronized clock boards where appropriate and a less accurate UDP broadcast time base everywhere else. This allows for a mixture of hardware and software timed devices with a reasonable degree of time base consistency. With this architecture, the entire system can be setup with as tight of a timing tolerance as desired based on client needs.

Data Merge

As mentioned before, data is merged at the end of the test without human intervention. This is accomplished with a multi-stage write process where each module stores its raw data to disk before passing it to the host for processing. This ensures that the client can recover the test date in the event of a processing exception.

Conclusion

Using a temporary or new instrument now requires a small amount of initial programming. Once integrated, the instrument can be removed or re-added by the client with no programming at all. This focus on just the instrument allows these new instruments to be integrated without fear that any other part of the system will be affected. For projects that need it, this new modular system dramatically increases the flexibility of a LabVIEW based system.

Comments

Shourya
# Shourya
Nice article. A simple example would have been very helpful for complete understanding.

Post a comment

Name (required)

Email (required)

CAPTCHA image
Enter the code shown above:

Related Blog Posts