Optimizing the Execution of Multithreaded LabVIEW with Windows NT

Author(s):
Richard Jennings - Sandia National Laboratories

Industry:
Government/Defense

Products:
Vision, LabVIEW

The Challenge:
Integrating several pieces of R&D laboratory equipment and computer systems into one easy-to-use tool.

The Solution:
Using the multithreading capability of LabVIEW to perform simultaneous image acquisition, data acquisition (DAQ), and motion control with one off-the-shelf PC with dual 400 MHz PII processors.

Introduction
National Instruments recently introduced a LabVIEW multithreading feature that runs code on multiple processors in parallel. Although we cannot assign tasks to specific processors, we maximize the use of several processors to prevent tasks from blocking each other. This article summarizes the development process and techniques used on a project at Lawrence Livermore National Laboratory (LLNL) to perform simultaneous image acquisition and processing, data acquisition and processing, and motion control in support of the world’s largest laser system, the National Ignition Facility (NIF).

Overview
The NIF is a 192-beam laser system that requires the delivery of more than 1,200 high damage threshold, meter-class, coated optical components before the 2003 completion deadline. The NIF optics group at LLNL increased the damage threshold of coatings on mirrors and polarizers by developing a process to condition each optic after it comes out of the coating chamber. The optic is mounted in a custom translation stage and the coated surface is scanned in a raster pattern through the waist of a high-power Nd:YAG laser running at 30 Hz.

We needed to perform continuous monitoring of coating quality and the process laser beam in parallel with motion control. To meet these requirements, we built the large area conditioning (LAC) system for continuous operation at the coating vendors’ facilities. The technical requirements for the LAC were well defined because the process had already been proven on a prototype system. Our goal was to integrate multiple pieces of equipment and the test procedure into one easy-to-use system capable of unattended operation.

Development
First, we broke down the largely manual prototype LAC into functional components, then decided how to optimize each component and how it would interact with the others. We broke the system down into three components - the beam profiler, the test code, and the user interface. Development of the beam profiler and the test code followed similar paths - with our programming, the hardware performs buffered acquisition directly to host RAM each time an external trigger occurs, processing the data as it becomes available. The user interface reads data from functional globals and displays it at 2 Hz. We developed and optimized each component before we integrated the system.

Our development machine was a Compaq AP400 with dual 400 MHz PII processors and 128 MB RAM running Windows NT. LabVIEW has multithreading capabilities for concurrent execution of processes on computers with more than one CPU. With a dual processor PC running Windows NT, we had the opportunity to try LabVIEW in a multithreading, multitasking, parallel processing environment for less than $5,000 (U.S.$).

The NT task manager gave us an idea of how efficiently our code used the processors and available memory. The internal profiler gauged how much time LabVIEW spent executing program (VI) code. More importantly, with the graphical display of the task manager, we visualized how changes in program structure affected the load on the computer. We wanted to ensure that no task would be starved for CPU cycles in the final product, so we set a development goal that at no time during execution would any single component use more than 50 percent of the processors. In the final product our total processor usage peaked at 95 percent.
We cut down on the time NT spent swapping data in and out of virtual memory by preallocating arrays and image buffers. By setting up our data and image acquisition to use circular buffers, we could perform other tasks while monitoring the buffers for new data. If the code processing the data in the circular buffer is delayed while other tasks are executing, it can catch up later as long as the data has not been overwritten. This feature turned out to be a key to our later success when we integrated the various components.
To monitor coating quality, we measure the amount of scattered light collected on a photodiode with a customized microscope system. The photodiode generates a DC voltage proportional to the scattered light. We measure this voltage before and after each shot of the 30 Hz laser with a National Instruments PCI-MIO-16XE-50 data acquisition (DAQ) card and analyze it in LabVIEW. If the difference in scattered light from before the shot and after the shot is above a predetermined threshold, the process stops before the next laser shot causes further damage. When the entire surface of the coating is conditioned, areas with a significant change during the test are photographed with a CCD on the microscope and National Instruments PCI-IMAQ 1408 analog framegrabber.

Precise measurement and control of the energy in the process laser is critical to laser conditioning of the coating. We delivered a self-calibrating instrument that runs 30 times faster than its predecessor by building our own integrated beam profiling system as a VI within LabVIEW using National Instruments digital framegrabber, the PCI-IMAQ 1424. Laser beam parameters display graphically. To change the energy, we type in a setpoint on a front-panel control.

LabVIEW handled all the details of splitting our code into threads for parallel execution on both processors. We had to determine whether to assign execution systems and priorities to each section of code or let LabVIEW use its default settings. We left the priorities at the default settings, but assigned separate execution systems to the top-level VIs of the beam profiler and the test system. We set all subVIs to run in the same execution system as the caller. With this strategy, our beam profiler and test system code run in parallel with only a few interrup-tions. Because we wrote our data into circular buffers, we overcome occasional delays.

Conclusion
We maximized the ability of LabVIEW to run code in parallel on a dual processor PC. Acquiring data into circular buffers each time an external trigger occurs gives us a system flexible enough to multitask without missing critical data. Rigorous testing of code to ensure that no single task dominated the host PC during development gave us a final product responsive and tolerant of demands put on it by the user interface (see figure above left).

For more information, contact:

Richard Jennings

Sandia National Laboratories

7011 East Ave. MS 9055

Livermore, CA 94550

E-mail: rtjenni@sandia.gov

Browse All Case Studies »