Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

why NIDAQmx?

Just discovered that traditional NIDAQ has the status "legacy software". What will happen with applications that are working only via (traditional) NIDAQ? I suspect that we will have to pay money for applications twice. In the nearest future we will have to buy the same application written for NIDAQmx to be able to work with new cards. What is the reason for this change?

0 Kudos
Message 1 of 3
(3,239 Views)
 

Excerpt from:

https://www.ni.com/en/support/documentation/supplemental/06/answers-to-frequently-asked-questions-ab...

Q: Why did NI create NI-DAQmx? Why not continue to develop Traditional NI-DAQ (Legacy)?

A: NI first released the Traditional NI-DAQ (Legacy) driver in the 1990s. Traditional NI-DAQ (Legacy) offered many improvements over existing DAQ libraries by providing extended functionality for a wide variety of devices. Improvements included double-buffered acquisition, built-in scaling for specific sensor types, such as thermocouples and strain gages, and signal conditioning, and a single library of functions that worked with multiple devices and OSs.

In the late 1990s, the NI-DAQ team recognized that the need to maintain API compatibility with previous releases increased the difficulty of adding new features and devices to Traditional NI-DAQ (Legacy). In addition, the Traditional NI-DAQ (Legacy) API, through its long evolution, had developed many problems that needed to be fixed. NI-DAQ developers were having difficulty intuitively extending the API and optimizing the increasingly broad spectrum of customer applications. NI concluded that a new API design and architecture would help NI-DAQ developers more easily add new features and new devices, fix many existing driver problems, and optimize performance at the same time.

Some ambitious goals of the NI-DAQmx project included the following:

  1. Make it easier to add new features to the DAQ API. The Traditional NI-DAQ (Legacy) API had many functions with a large number of parameters and no efficient way to add new parameters. The NI-DAQmx API, in comparison, uses a property-based approach with a rich property hierarchy. This property-based approach is easy to extend. Adding a new feature is often as easy as adding a new property.
  2. Make it easier to add new devices. NI had difficulty adding more devices to Traditional NI-DAQ (Legacy) without adding more bugs to existing functionality. Finding and fixing the accidental bugs took too much time each release. NI-DAQmx, in comparison, uses a componential plug-in design that facilitates adding new devices.
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
Message 2 of 3
(3,224 Views)

cont'd

  1. Make multithreaded data acquisition more efficient. Traditional NI-DAQ (Legacy) was initially designed for older OSes without multithreading. To run safely under a multithreaded OS, Traditional NI-DAQ (Legacy) restricts access to one thread at a time. For applications that need to concurrently perform two or more DAQ tasks, this restriction causes problems because both tasks cannot access the driver at the same time. NI-DAQmx solves this problem with a multithreaded design so that multiple threads can access the driver at the same time.
  2. Speed up DAQ performance, especially single-point performance. Some applications using Traditional NI-DAQ (Legacy) experienced poor software-timed single-point performance because they implemented expensive operations, such as validating the configuration (verify), reserving resources (reserve), and programming the hardware (commit) repeatedly in the main loops. Traditional NI-DAQ (Legacy) did not give applications enough control over when to perform verify, reserve, and commit, so users could not rewrite these applications to run faster. NI-DAQmx speeds up performance with a design based on a well-defined state model. NI-DAQmx provides users with advanced API functions, such as verify, reserve, and commit; therefore, users have more control over when to perform expensive operations.
  3. Improve driver quality and reliability. NI-DAQmx is designed with world-class data acquisition quality and robustness in mind. Since the beginning of NI-DAQmx development, every time a user adds a new feature or makes a change to the driver, a rigorous and comprehensive suite of automated functional and performance tests verifies that the change has not introduced a bug. This suite tests common and uncommon driver uses in a variety of device, sensor, and OS configurations. Uncommon or exceptional driver uses are important to overall reliability. NI-DAQmx is designed to handle exceptional conditions such as DAQ task abortion, watchdog timer expiration, and surprise device removal (such as unplugging a USB device from the computer).
    1. Make data acquisition easier. In the mid-1990s, the NI-DAQ team added an Easy I/O and Intermediate I/O layer to Traditional NI-DAQ (Legacy) to make some common DAQ tasks easier. However, the layered approach caused some problems because as soon as users needed to add more advanced features to applications, they had to rewrite the applications with the more advanced API. NI-DAQmx makes developing applications easier through the following:
    2. Configuration tools such as the NI-DAQmx DAQ Assistant. With the DAQ Assistant, users can graphically select the type of measurements they want to perform, save the configurations for later use, and generate code to include in applications.
    • Advanced NI-DAQmx routing features. These features simplify DAQ device triggering and synchronization.
    • Descriptive error reporting in NI-DAQmx. This feature helps users precisely identify the cause of an error and recommends solutions. Users have found that the advanced error reporting in NI-DAQmx makes debugging a DAQ application much easier.
    • Ease-of-use features beginning with LabVIEW 7. New features introduced in LabVIEW 7 that especially apply to NI-DAQmx include the ability to create Express VIs and polymorphic VIs. With Express VIs, users can replace large parts of a complex DAQ application with a simple configuration dialog. With polymorphic VIs, users can find features more easily. Because of both of these features, users develop applications in less time.
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~
    "It’s the questions that drive us.”
    ~~~~~~~~~~~~~~~~~~~~~~~~~~
    Message 3 of 3
    (3,222 Views)