In-Flight Stress Testing of Airplane Propellers Using LabVIEW
Author(s):
Dave Dodge - Focus Software Inc.
Industry:
Aerospace/Avionics
Products:
LabVIEW,
The Challenge:
Measuring fixed-wing aircraft propeller stress during flight.
The Solution:
Building a PC-based system using embedded strain gauges, custom conditioning and digitizing circuitry with a GPIB interface, and a PCMCIA-GPIB card controlled with LabVIEW.
"To solve this problem, we used queues, a new LabVIEW feature, with which you can store large amounts of data in RAM without using memory-intensive array or string operations. To solve the second problem, we used another LabVIEW feature -- multithreading."
Introduction
Focus Software, Inc. and Sensor Developments, Inc. teamed up to develop an application that measures stress on an airplane propeller during flight. Sensor Developments, Inc. developed custom data acquisition hardware that measures stress on a rotating propeller and transmits the data via GPIB back to the host laptop PC. Focus Software, Inc. then used LabVIEW to develop software that configures the hardware, reads and decodes the GPIB samples using a PCMCIA-GPIB card, and uses a postprocessing utility to export data in ASCII or DaDisp-compatible formats.
Hardware Design
Because of the uniqueness of the test, Sensor Developments, Inc. designed and built custom signal conditioning and data acquisition hardware, beginning with a rotating circuit assembly that digitizes the data from 32 strain gauges attached to the propeller. Because the rotating system "pipelines" the data through existing deicing slip rings built into the aircraft engine, there is no telemetry requirement. Thus, it is easy to install the system rapidly on many different types of aircraft. The data from the rotating circuit passes through the slip rings to a stationary circuit that converts the data to GPIB format and transmits it to a laptop PC. The laptop runs LabVIEW and uses a PCMCIA-GPIB card to read the data stream. To make data transmission as efficient as possible, the LabVIEW program receives the direct binary values from the 14-bit analog-to-digital converter (ADC) and later converts the data to engineering units.
Because these are in-flight tests, the team needed to design the tests with pilot safety in mind. We provided a simple remote pendant control attached to the flight stick to give the pilot control over the test sequences. With the pendant control, the pilot can safely start and stop the test with the laptop monitor out of sight. The pendant also has a series of LEDs to inform the pilot of the test status, as well as any error status. The pendant con-trol interfaces to a DAQCard-DIO-24 card.
Software Design Challenges
When designing the software, the biggest challenge Focus Software faced was through-put speed on the GPIB bus. Overall, there are 41 channels of data sampling at a rate of 6,000 S/s per channel. We also use a 2-byte separator between each scan of data. Each sample has 2 bytes of data, which means we need to read data at a rate of 504 kbytes/s over the GPIB lines. The hardware uses a 32 KB output buffer, thus requiring the software to read the hardware at a rate of more than 20 Hz. We found that streaming the data directly to disk on our laptop caused two problems:
- The program ran too slowly
- The output buffer overflowed, with loss of data
For the first problem, we took advantage of the 192 MB of RAM in our laptop by storing all the data in memory until the end of the test and then writing it to disk. But moving more than 30 MB of data (from a 60-second test) around in memory (with string concatenates and array builds) would slow the program down significantly. To prevent this problem, we used queues, a new LabVIEW feature, with which you can store large amounts of data in RAM without using memory-intensive array or string operations. To solve the second problem, we used anoth-er LabVIEW feature –- multithreading. By running the GPIB hardware calls in their own thread, we achieved the high speeds necessary to get all data without hardware buffer overflows. Data file management was another challenge we faced. Converting the raw data bytes to ASCII or DaDisp format required us to convert the file in small sections. Reading and converting an entire 30 MB file in memory took approximately five minutes with a Pentium II 266 MHz PC. Breaking the file into smaller pieces, however, reduced the conversion time to around 20 seconds.
Results
The system tests were very successful. The features of LabVIEW really were a lifesaver in this application. Using multithreading and queues, we quickly and efficiently read data from the GPIB hardware. Using the National Instruments PC cards, we housed this application in a laptop that fit behind the pilot’s seat. The PCMCIA-GPIB and DAQCard-DIO- 24 cards worked flawlessly.
For more information, contact:
David Dodge
Focus Software, Inc.
6111 Jackson Road, Suite 117
Ann Arbor, MI 48103
Tel: (734) 994-1505
Fax: (734) 994-1506
E-mail: dave@focussoftwareinc.com
Related Case Studies
LabVIEW and SCXI Provide a Configurable Measurement System for In-Flight HelicoptersChrysler RS Intelligent Power Module End-of-Line Tester
Using National Instruments Data Acquisition in a Microgravity Environment
LabVIEW-Based System Puts Dallas Transit on Track
Real-Time Wireless Data Acquisition System
|
|
