You have probably been in a project that was overdue because of a single technical hurdle. The problem may have been inadequate design from a vendor, bad documentation, or confusion about a product’s features. As an engineer or scientist trying to complete a sophisticated project, we’ve all been in that situation. A custom computer-based data acquisition (DAQ) system can be easy to design, but what do you need to know to avoid common design frustrations?
The key to meeting your project deadlines for data acquisition applications is not limited to understanding hardware capabilities. Any experienced technical support person for DAQ products will tell you that inadequate driver software features or poor driver software performance will make their phone ring more and will flood their inbox. Driver software links your DAQ system to two types of software: application development environments (ADE) and turnkey software.
ADEs are programming environments like LabVIEW or visual basic that allow you to build and customise a programme to your needs. Turnkey applications are pre-written programs with limited functionality, but they require no program skills from you. Turnkey applications are nice for very simple projects, but they are dangerous to your project deadline because a 'simple' feature that you might need can be nearly impossible to introduce into the pre-written turnkey software. When you use any major ADE, however, a hardware vendor or a general Internet search should provide plenty of example programs. The example programs are just like having turnkey software, but with one distinct advantage: you can customise the program if necessary. Before deciding on the hardware for a DAQ system, it might be a good idea to see what example programs are available to you for the ADE of your choice.
Once you think that you have found a software example coming close to fitting your needs, the next step is to decide what kind of hardware will work for your application. A data acquisition board, although a standard term, does more than just acquire data. Most DAQ boards have multiple functions, including the ability to generate both analog and digital signals. However, the purpose of these analog and digital outputs is to provide control and stimulation, so that you can ultimately acquire a signal from the outside world. General plug-in measurement hardware for PCs can range from extremely accurate measurements with less than a few microvolts of error to very fast measurements with sampling rates in the GHz range. The less expensive and higher channel-count genre of DAQ systems, though, serve a lot of applications at just a few hundred kHz for the sampling rate and overall accuracy of at least a few millivolts. DAQ systems include the multifunction plug-in board and the appropriate signal conditioning and amplification for the input signals. The real value of this popular type of DAQ system is its ability to synchronise operations and capture just the measurements you need, provided by thorough timing and triggering options.
Software plays a crucial role in developing the right timing and triggering, even for the very basic applications. Consider a temperature monitoring application that is controlling a heating unit. There are plenty of example programs demonstrating temperature monitoring and control, but would you ever need to customise any timing operations in this application? First, you have to decide how much variation in the timing that you can tolerate. When running a programme in any common version of Microsoft Windows or Mac OS, you should expect variations in software timing as large as a few milliseconds, depending on the speed of the computer and other applications running at the same time. Since temperature changes are relatively slow, variations of 10 milliseconds in your sampling intervals may be acceptable. Variations like this are not acceptable, however, when you have a control loop tightly regulating this temperature, or when you are using over-sampling and averaging techniques to cancel noise and improve measurement quality.
Many control applications require a realtime operating environment unlike Windows or Mac OS, so let us assume that you do not need perfect control loop timing. Instead, you are controlling a simple on/off heating element with a digital output from your multifunction DAQ board, and you want to minimise variation in the time between temperature samples. Computer speed and program efficiency will all help minimise variations in time between samples, but efficient driver software will avoid any major delays between your analog input samples. When your software goes to change a digital output and control the heater, this should not cause the rest of your program to come to a halt. Your driver software should be able to perform multiple functions simultaneously without holding up the rest of your software program.
If you decide to analyse, graph, or save the temperature measurements, you might want to increase the accuracy of your measurements by over-sampling and averaging. Since the most common source of noise on a signal is power line noise (50 Hz noise in South Africa), you can sample at an even multiple of one of these frequencies, then average the measurements in software to get a much better temperature reading. 100 samples/sec, for instance, would be a good sampling rate for averaging out 50 Hz power line noise. This sampling rate would require samples at precisely 10 ms intervals. In this situation, you would have to set up a hardware timer on the DAQ board to control the sampling rate instead of calling for samples in a software loop. Adequate driver software will allow for both of these options, but superior driver software will allow you to continually sample at 100 samples/sec, and it will manage all of the software and hardware buffers automatically without the risk of losing data.
So far, this simple temperature and control application would have benefited from continuous, hardware-timed analog input and simultaneous digital output, all with driver software that offers really good performance, minimal overhead delays, and minimal programming frustrations. Although these were key features in this simple application, you can see how a potential system designer could overlook these considerations when making a purchase.
Triggering is another aspect of the software and hardware design that could prove very useful in the example temperature application. A flexible triggering system will offer easy-to-use software options to allow a start and stop trigger with a digital signal or analog reference point. Analog triggers are especially useful because they allow you to capture only the data you need. A single voltage level trigger can be useful for thresholds, but really good driver software will also allow easy access to more robust triggering options like windowing and hysteresis.
Windowing and hysteresis both require you to choose two trigger levels. With windowing, the DAQ board will sample the analog input channels only when the signal is within the two trigger levels or outside of the trigger levels, depending on your preference. Hysteresis, on the other hand, allows for the samples to be taken only after both trigger points have been crossed by the signal. This is a helpful triggering technique for the temperature monitoring and control example: If you are monitoring the temperature for a long period of time, you might want the DAQ board to take the temperature measurements only when the temperature drops below a certain level. This might seem at first like a single level trigger, but hysteresis can be used here to enhance a single level trigger. For example, you might want to monitor the temperature only when it drops below 60°C, and stop monitoring the temperature if it rises above 61°C. If you set the analog triggers for hysteresis triggering mode at 60 and 61°C, the DAQ board will not start acquiring data until the temperature reaches 61°C and drops below 60°C again.
Some DAQ boards do not have analog triggering, as this feature requires extra cost in DAQ board parts and design. Good driver software, however, can compensate in some situations with a feature called conditional retrieval. Conditional retrieval sets the DAQ board to acquire data continuously into a software buffer, but none of the data is actually returned to your program until certain conditions are met. Unlike true hardware triggering, this feature does require constant computer and CPU resources, but it should not add any programming difficulties with good driver software. Conditional retrieval can actually offer an advantage over analog triggering in some situations. Consider again the temperature monitoring example: The analog trigger circuitry might only have 8-bits of resolution, but your DAQ board may have 16-bit resolution. Since the conditional retrieval option is using the 16-bit analog-to-digital converter on your DAQ board instead of the 8-bit trigger level, you have more options for trigger levels. The smallest detectable voltage change with 16-bit resolution is 256 times smaller than an analog trigger with 8-bit resolution.
It is always difficult to anticipate all of the hardware and software features you might need before even starting an application. Searching for similar application examples from your hardware vendor is a good start to anticipating some of your needs, but another very useful technique is just to talk to their technical support. A lot of hardware vendors will answer technical questions about the driver software over the phone, by e-mail, or on the Web before you decide to purchase a product. Will the driver software allow for multiple operations simultaneously? Is it easy to set up an application using hysteresis? Questions like these could save you crucial programming time and frustrations, and at the same time allow you to test the quality of the technical support just in case you need it later.
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version