University College London – Towing Tank Datalogging System

Summary

• A robust data acquisition system that allows users to connect wirelessly while the Towing Tank is running a test.
• Recording of configurations means multiple tests can run off the same loaded configuration without having to re-enter the data each time.
• All data acquired is stored locally on the cDAQ, to ensure that any drop in connection doesn’t affect or stop the data being recorded and can be accessed once a connection is re-established.
• A watertight housing ensures a longer lifetime in the harsh moist environment and is resistant to water ingress, therefore, less likely to require repair if placed in a body of water.

Background

The Ocean Towing Tank, UCL, Department of Mechanical Engineering, is a 20-metre-long tank that simulates the type of fluid flow found in deep water waves. 2.5 metres wide and 1m deep, it is housed in the basement of Robert’s Building on Torrington Place.

Naval architects and other engineers at UCL use it to see how their designs interact with waves. While computer simulations are very sophisticated and can do a lot, experiments are still needed to check the accuracy of their predictions.

Challenge

Austin Consultants was tasked with aiding the upgrade of UCL’s Towing Tank system by providing an on-board Datalogging system which would allow UCL to run experiments such as resistance and seakeeping tests. Due to the nature of instruments used during a test UCL required a system that would provide the recording of analog and digital data. The system had to be waterproof due to the harsh environment that the tests would be carried out in and also had to be able to connect wirelessly due to the constant movement of the Towing Tank system.

Based on these requirements, Austin Consultants set out to create a Datalogging System contained inside a watertight enclosure which would connect either wirelessly or wired to a PC. The PC would run an executable to allow the user to interact with the Datalogging system to configure experiments as well as retrieve data.

Solution

Hardware

Within a watertight enclosure, we placed a National Instruments real-time cDAQ. A real-time (RT) cDAQ was chosen over a traditional cDAQ to provide on-board Datalogging. This means that any drop in the connection between the PC and cDAQ would not disrupt the actual logging of data to a file. An 8 slot chassis was also selected to allow for further expansion of the system in the future. Three modules were selected to be used with the cDAQ to facilitate the Datalogging process:

• 1 X NI 9205 32 Channel Analog Input Module,
• 1 X NI 9211 4 Channel Thermocouple Input Module,
• 1 X NI 9401 8 Channel Digital Input/Output Module,

The enclosure also had a Moxa AWK-3121 Access Point which aids in the wireless connectivity between the enclosure and the PC.

The exterior of the enclosure housed watertight connectors for:

• 8 analog input channels, with power connections, if required
• 1 digital input channel
• 1 antenna adapter for the Moxa AWK-3121
• 1 ethernet port
• 1 power input

To connect to the enclosure we provided UCL with 3 analog connections (2 LVDT’s and 1 single axis strain gauge) as well as the wiring diagram for these connections to allow UCL to use different analog inputs in the future.

Software | PC Application

The software utilised National Instruments LabVIEW to create both an RT and PC application for the system. LabVIEW was chosen for the application as it was simple to create a PC application with easy to follow interfaces as well as having the built-in requirements to create a reliable RT application for the cDAQ. The PC application would hold the information for the configurations of the system and allow for data streaming, whilst the RT application would allow for onboard Datalogging.

An important requirement for the interface was that coding of indicators and graphs had to be adaptable and not rely on colours only so that they were easier to distinguish and understand by anyone, including those affected by colour blindness. We were able to utilise LabVIEW’s built-in indicators and graphs to make these easily readable by adapting each indicator to show a different symbol for each state and modifying how a graph is represented to the user by displaying plots with dashes and adaptive plot thickness.

When the system first loads, connectivity checks are performed to make sure the PC and RT applications can connect to each other. If a connection times out, the system will continuously try to reconnect first by the wired connection and then by wireless connection until either the system is closed down or a connection is re-established. The software indicates via an on-screen status bar if a connection has been established and also displays how much space is left on the SD card housed in the cDAQ.

The application is adaptable to accommodate any possible required configuration of the 8 analog input channels and allow configuration profiles to be saved. The configuration setup incorporates a simple calibration process that provides a scaling factor for raw input data so that voltages that are stepped down for the +-10 V analogue card can be scaled back up again using the software to show true values. Configuration profiles include data about the channel as well as the test parameters such as sampling frequency and filter type. All configuration data is saved down to a .xml file and can be easily loaded back into the system, adapted and saved as a new configuration profile.

Having been created on the PC a test configuration is sent to the RT data logging application based on the cDAQ using inbuilt LabVIEW Data Streams. When the user selects start data is logged by creating a file on the RT SD card and stored based on the configuration input selected by the user. The Data logging module on the PC also displays the data at a rate of 1Hz to allow the user to check the averaged data from the system and that the system is performing as required.

Once the test has finished, stop logging data is selected,  data logging ends and prompts on the PC application allow the user to input a comment into the saved file describing any incidents that may have occurred when running the test. The user can then use the same configuration to run another test or load further configurations into the system.

Retrieving the saved files from the SD card on the cDAQ is made possible by the built-in FTP functions within LabVIEW. The user can also select to delete files on the SD card to free up space when required.

Software | Real-time Datalogger Application

The system utilises a real-time cDAQ to allow data to be processed without risk of any data loss to the PC application if the connection is lost.

The real-time (RT) application features several functions from acquiring data and scaling to building and logging TDMS files to store data.

When the system is in an idle state, the RT application sends data to the PC at a rate of 1Hz, this data is not scaled and is generally used to make sure a connection is still established between the two applications.

Once the user selects a configuration profile on the PC to start data logging, the configuration is sent to the RT and is handled in separate states to allow the RT to function correctly. The channels to be recorded and sample rates are sent to the DAQmx module, the multiplier and offsets are sent to the Scaling module and configuration data is sent to the Logging module so that when the TDMS file is read at a later date, the user can see all configuration parameters for that test. The TDMS file has a unique name as determined by the data that was entered for the configuration. This includes the Username, the Test Type, the Model Reference and either the Date and Time or a unique identifier supplied by the user.

The DAQmx module uses built-in LabVIEW DAQmx functions to create analog and digital tasks for the system to be able to read data from the cDAQ modules. Using user events this data is passed to the Scaling module where the multiplier and offset for each channel is applied to their respective data. Once this data has been scaled another user event is triggered and the scaled data is passed to the Logging module where the data is stored in a TDMS file format. This procedure is repeated until the user stops logging data.

When logging has finished, the DAQmx module returns to a 1Hz rate to allow data to be streamed back to the PC application and allow the user to see a connection is still established.

Benefits & Results

The new system not only addresses UCL’s requirements for reliable and consistent test monitoring, wireless connectivity and a robust housing but also provides an adaptable and extendable platform that can easily accommodate new and changing demands.

The simple integration between the cDAQ, RT application and the PC application was possible by using LabVIEW. Due to the flexibility of the cDAQ and the modular approach of the software, it is possible to upgrade the system and allow for more modules to be added to expand the functionality of the system as a whole.

• 

  Data logger in situ

  Increased performance, monitoring, and data capture.

• The totally configurable system allows users to remap channels and reconfigure the system as required.
• The software application is very flexible allowing complete configuration of the system and tests.
• The user interface is clean, resizable and intuitive to operate.
• Users can create and save test configuration profiles for easy reuse.
• The systems modular software architecture enables simple future expansion with additional modules.

PHASE 2 – CARRIAGE AUTOMATION UPGRADE | SEPTEMBER 2018

In 2018 UCL contacted Austin Consultants to undertake an upgrade to the data logging system. The motor that drives the carriage on which the data logger runs was previously controlled using a separate HMI fixed to a nearby pillar. The HMI had to be manually configured and operated each time a test was run. The team at UCL wanted to be able to integrate communication and control of the carriage motor into the LabVIEW system setup. 

Our team integrated the motor control to allow the operator to set the carriage to automatically run up and down the tank whilst acquiring the DAQ data wirelessly from the cDAQ. The operator is now able to configure parameters including acceleration, deceleration, speed and torque. 

The fact that this is all now controlled from LabVIEW means that the carriage can be sequenced in advance, sequences can be saved for easy reuse and the system can now be managed by one operator from a desk at the end of the tank; saving time and making the testing process more efficient.

More projects