The data logger has been around for hundreds of years, evolving from an assistant with paper and pencil to the technology-packed, automated device available today. Much like how hammers are tools for carpenters, data loggers are tools for scientists, engineers, and anyone else working in a measurement environment. Also like hammers, there are several options from which to choose, yet the cost-conscious consumer wants to own as few as possible.
Until now, data loggers and their associated software applications have been very purpose-specific. These purposes range from portable devices used in the field to simple benchtop testers to advanced, ruggedized, in-vehicle data loggers for road testing. The nearly infinite range of use cases coupled with the fixed functionality of most data loggers demonstrates the need for multiple devices, and thus expenditures, for each project.
Solutions as varied as requirements
Communication buses such as serial, Ethernet, or USB were
added to data loggers to enable computer connectivity when desired, and memory
card slots were integrated for expandable storage options. The line between a
PC-based data logger and a stand-alone data logger continues to blur as more
devices such as processors and FPGA[
] chips leverage PC technology for flexible
performance.
Modular hardware is a great concept, but a desktop data logger that plugs into the wall usually takes different modules than a compact, DC-powered data logger that can be installed in-vehicle or a small portable data logger that can be used with a laptop. Modules can reduce hardware cost if implemented correctly or can compound the problem of overloaded equipment libraries if designed or purchased without thought.
A better ecosystem for logging
A flexible data logger that can be retasked and reused as projects grow and change could alleviate these issues. In this case, flexibility is more than just the capability to add modules or adjust the file type. To encompass a wider range of applications, the next evolution of data loggers ideally should comprise a larger family of products with the ability to swap not only modules but also deployment systems and software. With a focus on both flexibility and performance, instrumentation vendors would be able to create a data logging ecosystem that could meet a larger spectrum of data logging use cases, allowing companies to reduce their equipment spending, support, and training costs.
One such example of a data logging ecosystem is the C Series family of data logging hardware from National Instruments (see Figure 1). This family is based on more than 40 modules that contain all the signal conditioning, data conversion, and connectivity needed in a small, metal, rugged housing a little larger than a deck of cards. By isolating the measurement to the module, end users can expand their systems by purchasing new modules and vendors can expand the data logging ecosystem by developing more modules.
The C series family of hardware can be deployed in several different ways, with modules, several chassis, and carriers used for different tasks (see Figure 2):
- For low-cost, low-channel count, or portable applications, the single module carrier logs data directly to a PC via USB.
- For multiple measurement types, modules deploy a larger USB CompactDAQ chassis that supports and synchronizes data from up to eight modules.
- For more harsh environments or smaller spaces that exclude full PC use, the family incorporates CompactRIO, which has built-in processing and expandable storage. No PC is needed for CompactRIO deployment, and its rugged 50 g shock and a -40 ∞C to +70 ∞C environmental operating range allow this system to go where several other data loggers would fail.
One set of modules and multiple deployment options effectively means a portable system, benchtop system, and installed system all can potentially use the same exact module.
Software just as important
Hardware is only part of the data logging ecosystem. Even with the most flexible hardware, functionality is still restricted and defined by the software controlling the data logger. The proper software interface for an effective data logging ecosystem is one that can change functionality or be reused on different hardware when needed. In a scalable solution, the software portion of the evolved data logger should be flexible and range from a low-cost simple solution to a more advanced solution that can add analysis and log data to custom file formats.
Most data loggers have the simple end covered with included turnkey software and the advanced end covered by programming languages such as ANSI C, Visual Studio, and LabVIEW. Few data loggers can bridge the gap and allow scalability from the low end to the high end, but the C Series family when programmed with LabVIEW spans this range.
On the low-channel count end, USB hardware comes with logging software that will log data to disk with minimum setup. As the project grows, features such as triggers, alarms, and outputs can be added. Ultimately, the project can be converted into LabVIEW code for complete processing and logic capability as well as data storage format customization.
Moving from the benchtop to the field with hardware is as easy as moving modules from one chassis to another, but what about the software? LabVIEW code can be written so that, with little or no modification, it can run with a wide range of hardware: the single, portable USB carrier, the eight-slot USB CompactDAQ carrier, or the embedded CompactRIO data logger with onboard storage. The modules selected and software configured or programmed usually represent the majority of time and cost when implementing a system. The ability to transport this sunk cost from one phase of a project to the next adds value far beyond the cost of the actual instrumentation.
An example: brake rotor design test
As an example of the data logger ecosystem concept at work in the C Series, consider temperature logging for an automotive brake rotor design.
For early, small-scale design testing, the single module carrier can be implemented for low-channel thermal tests on different metal thicknesses or different hole patterns for vented discs. The test engineer develops the simple software application in LabVIEW for use with the single module carrier.
Later testing of the brake rotor can involve a test setup on a dynamometer where more of the modules are purchased and installed into a larger USB CompactDAQ chassis. With minor tweaks on the software, the same analysis and code from earlier testing can be reused completely on the dynamometer. At this stage, accelerometers can be used for vibration analysis on the suspension system. An accelerometer module also can be added to the system and code added to the existing program to perform analysis or, with no modification, the program can simply log vibration data in the same file as the existing temperature data.
The final testing stage of the brake rotors is real-world test track logging. This is a different deployment paradigm than the previous two as, in this case, the power available is different, the environmental conditions are harsher, and a laptop may not be a feasible option. For this test, the same modules and code can be transported to CompactRIO for the road tests, with a built-in controller and storage. The same data file can be collected via an SD memory card, serial interface, TCP/IP interface, or even over wireless if an 802.11 network can be set up around the test track. Each phase in this testing process uses the same data logging vendor, software, and modules.
This example represents retasking and reusing a system for a single project. Once the brake rotor is designed and out the door, future projects could involve testing the exhaust, designing a new spoiler, or monitoring manifold pressure from a new engine block. Fortunately for this project team, there was no need to design around a brake rotor data logger or even a standard temperature data logger; they designed into a data logging ecosystem, so with each new program they can retask the hardware for any new project. Whether the project team consists of one person or an entire building of people, the result is greater productivity.
Brett Burger is a product marketing manager for data acquisition systems at National Instruments in Austin, Texas. He started his career at NI in 2003 as a member of the engineering leadership program where he served as a team leader and provided technical support for top accounts. Brett graduated with a BS in Aerospace Engineering from Texas A&M University.
National Instruments
512-683-0100
