The data logger has been around for hundreds of years evolving from an assistant with paper and pencil to the technology packed, automated products that they can be today. Much like hammers are tools to carpenters, data loggers are tools to scientists, engineers, and anyone else working in a measurement environment. Also like hammers, there are several options from which to choose yet the cost-conscience consumer wants to own as few of them as possible. Unfortunately, data loggers and their associated software applications have been very purpose specific. These purposes range from portable devices used in the field, to simple bench-top testers, to advanced ruggedised in-vehicle data loggers for road testing. The infinite range of use cases coupled with the fixed functionality of most data loggers means you have multiple devices, and thus expenditures, for each project.
Convergence and modularity
Data loggers have many features, including measurement type, number of measurements, storage mechanism, storage space, environmental operating conditions, signal processing components, display device, reporting procedure, controlling or analysing software and many more. These data logger characteristics dictate hardware needed for a project and in many cases changing just one of the requirements will result in the need for a new piece of instrumentation. Sometimes this new instrumentation is a different model line from the same vendor but often it is from a different, more specialised vendor meaning multiple support contacts, hardware standards, and purchase orders to keep track of. Instrumentation and data logger venders have been working towards a solution to this problem over a series of hardware evolutions. Open file formats such as ASCII, or .CSV files are used by data loggers that store to a disk in order to be more 'software flexible'. Modular systems were introduced to the data logging market allowing users to expand the channel count or even measurement type of the data logger. Communication busses such as serial, Ethernet, or USB have been added to data loggers to enable computer connectivity when desired, and memory card slots have been integrated for expandable storage options. The line between a PC-based data logger and a standalone data logger continues to blur as more devices leverage PC technology, such as processors and FPGA chips, for flexible performance.
Modular hardware is great but the desktop data logger that plugs into the wall usually takes different modules than the compact, DC-powered data logger that can be installed in-vehicle, or the small portable data logger that can be used with a laptop. Modules can reduce the cost of hardware if implemented correctly, or they can compound the problem of overloaded equipment libraries if designed or purchased without thought.
True flexibility – the data logging ecosystem
What is needed is a flexible data logger that can be re-tasked and re-used as projects grow and change. 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 needs to be a larger family of products that have the ability to swap not only module, but deployment systems and software as well. With a focus on both flexibility and performance, instrumentation vendors can create a 'data logging ecosystem' that can 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. The C Series family is based on over 40 modules that contain all of 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 the vendor can expand the data logging ecosystem by developing more modules. The C series family of hardware from NI is not the only product or company that is utilising a modular based system and one of the ways the hardware from National Instruments differs is in the deployment of these C Series modules. For deployment, the C Series family consists of several chassis and carriers for different tasks. For low-cost, low-channel count or portable applications, the C Series single module carrier will log data directly to a PC via USB. The next step for growth or for multiple measurement types is to deploy in the larger USB CompactDAQ chassis which will support and synchronise data from up to eight modules. Both the single module carrier and CompactDAQ are used for PC deployment but many data logging applications are in more harsh environments or smaller spaces that exclude use of a full PC. For these scenarios, the C Series family has CompactRIO which has built-in processing and expandable storage. No PC is needed for the deployment of CompactRIO and its rugged 50g shock and -40°C to 70°C environmental operating range means this system can go where several other data loggers would fail. One set of modules and multiple deployment options mean a portable system, bench-top system, and installed system can all possibly use the same exact module.
Hardware is only part of the data logging ecosystem as even with the most flexible of all hardware the functionality is still restricted and defined by the software that is controlling the data logger. The proper software interface for a good data logging ecosystem is one that can change functionality or be re-used on different hardware when needed. Keeping with a scalable solution, the software portion of the evolved data logger needs to be flexible and range from a low-cost simple solution all the way through a more advanced solution that can add analysis and log data to custom file formats. Many data loggers have the simple end covered with included turn-key software, and the advanced end is covered by programming languages such as ANSI C, Visual Studio, and LabVIEW, but few can bridge the gap and allow scalability from the low end to the high end. The C Series family, programmed with LabVIEW can. On the low-channel count end, the USB C Series 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 customisation of data storage format.
Application portability
Moving from the bench-top to the field with the hardware is as easy as moving modules from one chassis to another, but what about the software? LabVIEW code can be written that, with little to no modification, can run with the single, portable USB carrier, the 8 slot USB CompactDAQ carrier, or the embedded CompactRIO data logger with on-board storage. The modules selected and software configured or programmed will 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.
A practical example
It is important to note that a good data logging ecosystem will have components that allow you to scale a project from the low-cost, low-channel count design research, to the full featured embedded logging system used in prototypes. To use the C Series family as an example we can look at temperature logging for automotive brake rotor design. For early, small scale design testing the single module carrier can be used for low-channel thermal tests on different metal thicknesses or maybe different hole patterns for vented discs. For this example we will have the test engineer develop the simple software application in LabVIEW for use with the single module carrier. Later testing of the brake rotor may involve a test setup on a dynamometer where more of the same modules could be purchased and installed into a larger USB chassis, NI CompactDAQ. With minor tweaks on the software, the same analysis and code from earlier testing could be re-used completely on the dynamometer. Maybe at this stage accelerometers would be used for vibration analysis on the suspension system. An accelerometer module could be added to the system and code could be added to the existing program to perform analysis or, with no modification, the program could simply log vibration data in the same file as the existing temperature data. The final testing stage of the brake rotors would be real-world test track logging. This is a different deployment paradigm from the previous two as now 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 NI CompactRIO for the road tests. CompactRIO has a built in controller and storage. The same data file can be collected via SD memory card, serial interface, TCP/IP interface, or even over wireless if an 802.11 network can be setup around the test track. Each phase in this testing process used the same vendor, the same software, and the same modules.
This example represents re-tasking and re-using a system for a single project. Once the brake rotor is designed and out the door the next project that comes in may be to test the exhaust, design a new spoiler or monitor manifold pressure from a new engine block. Fortunately this end user did not purchase a brake rotor data logger, or even a standard temperature datalogger, (s)he purchased into a data logging ecosystem ie, with a new program the hardware can be re-tasked for future projects. Whether a test department is one person or one building, the result is greater productivity.
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version