DAQmx Multi-Device Streaming Reference Example

This example program demonstrates a flexible, scalable architecture for reading inputs from several different DAQmx devices and streaming the data directly to a binary file on disk. It utilizes VI Server and event-based DAQmx to simplify adding and removing tasks while maintaining adequate headroom in the CPU for data analysis and processing.

**The accompanying code represents a very specific use case for NI products. For more general examples, please refer to ni.com/examples, the LabVIEW Example Finder, or the NI driver help files that come with every NI driver.

Hardware Overview

PXIe-1065 18-slot hybrid PXI Express chassis
PXIe-8130 controller
Various M-series and S-series DAQmx modules

Software Overview

This VI uses an array control on the front panel to specify the channels and sample rates for the DAQmx tasks. Initialization SubVIs at the start of the program initiate the DAQmx tasks, calculate read rates to synchronize the tasks, and initialize data queues. Each task then utilizes VI Server to create an instance of a cloned SubVI to read the task's data. The data is passed back through a queue, and the task status is updated through a functional global variable. While data is being acquired, the main VI monitors the status of the DAQmx tasks through the functional global variable, removes the acquired data from the queues, and writes it to a binary file using the Win32 File I/O API. The VI can also optionally decimate the data from certain queues and perform basic processing (limit checking, etc.) before writing it to a file. The system was designed to be as modular as possible--both in functionality (using SUbVIs to modularize functionality) and data (through the use of clusters and typedefs to group related data). It also takes full advantage of the multicore capabilities of LabVIEW for improved performance.

 

Design Highlights

Serial vs. Parallel Architecture

When designing a system with multiple DAQmx tasks, the basic architecture can be serial or parallel.

In a parallel architecture, all of the DAQmx tasks are configured at the same time, and all tasks are read or written simultaneously in a single loop. This can provide a performance advantage, since LabVIEW will perform the multiple parallel reads in multiple processor threads. In addition, data can be read on each task independently as soon as it is ready, which maximizes the efficiency of each iteration of the loop.

However, a serial architecture is much more scalable. By using auto-indexed For loops, tasks can be added or removed by simply adding or removing elements in an array control, instead of manually and removing code. This makes the system much more scalable; however, there are performance concerns with a serial architecture. Since data reads must happen sequentially, there is an increased risk of buffer overflows.

Using VI Server and SubVI clones can provide the scalability of a serial architecture while providing the multithreaded read/write performance benefits of a parallel architecture. This example utilizes a single DAQmx Read operation inside a while loop in a SubVI. Clones of this SubVI are created serially using VI Server. The clones run in parallel during the acquisition phase, and they communicate data and status information back to the main VI using queues and functional global variables. This takes full advantage of the multicore capability of LabVIEW through the use of parallel loops. While this setup is considerably more complicated to code and troubleshoot, it provides the benefits of both the serial and parallel architectures.

Polling vs. Event-Based DAQmx

[+] Enlarge Image

The traditional DAQmx programming model for acquiring a specific number of samples involves simply placing a DAQmx Read VI inside a while loop and wiring the Samples to Read terminal. When execution reaches the DAQmx Read VI, LabVIEW will attempt to transfer the specified number of samples from the DAQmx buffer. If all of the samples are not present in the buffer, LabVIEW will continuously read the number of samples in the buffer until all of the data is available. This minimizes the delay between acquisition of the samples by the driver and retrieval of the data by LabVIEW, but the requests for data put a considerable load on the CPU. This is the default behavior of the driver, and it provides the best performance for systems with a few DAQmx tasks.

However, if multiple tasks are running concurrently, the CPU can quickly become overwhelmed by all of the tasks trying to retrieve their data. An alternative is to use DAQmx Events. Instead of LabVIEW continually polling the driver to read a specific number of samples, LabVIEW can wait to receive an event from the DAQmx driver indicating that the samples have been acquired. The waiting requires negligible CPU usage, and the performance loss compared to polling is minimal.

In-Place Element Structures For Performance

During the acquisition and streaming phase of this program, performance is crucial. One important way to optimize this phase for maximum performance is to avoid memory allocations wherever possible--especially large arrays. This program makes extensive use of the new in-place event structure in LabVIEW 8.5 to ensure that data arrays are copied as few times as possible.

Requirements

Filename: daqmx_streaming.zip

Software Requirements

Application Software: LabVIEW Professional Development System 8.5
Language(s): LabVIEW

Hardware Requirements

Hardware Group: Multifunction DAQ (MIO)
Hardware Model: PXI-6133
Driver: NI-DAQmx 8.7

Reader Comments | Submit a comment »