To increase development efficiency, each NI driver offers a broad portfolio of example programs, supports a wide range of measurement devices, utilizes a common programming flow, and provides multiple layers of device configuration.
Utilize Example Programs
Often, as a test engineer, you do not have time to learn a new set of tools for each test system you build. Moreover, you need to use your current knowledge without slowing down productivity with additional training. NI drivers come with a large breadth of example programs created and vetted by NI’s research and development team so that you can begin with prebuilt code and modify it to fit your needs. In each driver set, you will find example code that aligns with various testing needs, whether you’re utilizing NI-SCOPE to create voltage histograms or using NI-DCPower to conduct a hardware-timed two-channel sweep. All example programs come with detailed documentation to explain how to implement them, and, when applicable, include prebuilt user interfaces. By beginning the programming process with relevant example programs, you decrease time spent learning new driver operation.
Figure 3. NI-SCOPE Voltage Histogram User Interfaces with LabVIEW (Left) and C# (Right)
Integrate Multiple Devices
Integrating new devices into a test architecture can be a major effort, often taking more time than the programming, measurement, or test itself. Integrating different hardware devices can require learning how to call each device’s driver from development environments. NI’s driver portfolio removes this risk by supporting multiple measurement devices with a single driver. In some systems, such as those using NI DAQ hardware, you can program the entire system using one driver. For instance, use NI-DAQmx to integrate more than 200 NI data acquisition devices on a variety of major buses and form factors. In other systems, NI drivers cater to specific measurement types, such as the NI-FGEN driver that supports NI waveform generator products. This level of device support means that you can reuse code—if you transition to using hardware with higher sample rates or resolutions, for example, you only need to modify a portion of the code to adapt to new capabilities, as the new hardware is supported by the same driver. Seamlessly integrating multiple measurement devices within a single driver achieves efficiency with multiple instruments and reduces the amount of time spent learning new driver commands.
Employ a Consistent Programming Flow
Additionally, with the NI driver portfolio, you easily can transition between different sensor types and measurement devices because the drivers use a consistent programming approach. Application flow typically starts with opening a connection to the hardware and then configuring hardware settings, reading and writing measured data to and from the hardware, and finally, closing the connection to the hardware. Because most drivers follow this framework, learning how to program an instrument with a new driver is relatively easy, saving development time.
Figure 4. Programming NI hardware follows a common framework.
Figure 5. NI-SCOPE Programming Flow
Figure 6. NI-DAQmx Programming Flow
Access High- and Low-Level Device Configuration
NI understands that test engineers often do not prefer or have time to configure every low-level feature within an instrument, so NI drivers offer high-level, easy-to-understand operations. You can utilize the majority of hardware functionality quickly, without having to be exposed to low-level hardware configuration. However, when you need to fine-tune tests, you still can access the low levels in NI drivers. For example, when programming a new automated test design, you can choose to exclusively configure high-level, standard settings, such as sample rate and input voltage limits, using the add channel function. Or you can further configure the design by programming the input and output buffers using the respective functions. With NI drivers, you choose what needs to be configured outside of the typical constraints. Also, you are not required to learn the specifics of how data is communicated back and forth between the hardware and computational devices, and even though you might use several different protocols in the same application, you only need to learn one approach.