The Goal: Extend the life of helicopter rotors and save millions of dollars

Helicopter Transport Services, Inc. (HTSI) owns a fleet of firefighting helicopters that was destined for the scrap heap unless the service lifetime of their rotors could be extended. To do this, they needed to demonstrate to the FAA that even though the rotors were old, they’d never been used as hard as they were designed for. To make their case, they’d somehow have to measure the behavior of the rotors in-flight. HTSI hired FAA-certified principal engineer Dave McClenahan to oversee the testing and analysis. Dave hired engineer Dick Meridith to attach strain gages to the air frame and rotor and collect data during as a helicopter was put through its paces. A consultant was enlisted to write the collection program, which he promised to do while on a vacation from his day job. The vacation ended and there was no working program and time was running out, so Dick asked National Instruments what he should do. After a call to Moore Good Ideas (MGI), David Moore was on a plane the next day.

The Issues

The first issue: Could MGI just finish off what had already been written? MGI always tries to save our customers time and money by reusing existing code. For example, one of our customers had an old data acquisition system that pumped data right into Excel where the customer did all their analysis and reporting. With the implementation of MGI’s advanced, new acquisition system, would the data show up in the old spreadsheets just like it used to? Of course! All the customer’s investment in their spreadsheets was saved. Another example involves a pair of MGI customers who had old control systems that were already LabVIEW based. One customer blows up automobile airbags and the other blows up rocket motor cases. Neither one liked it when their old LabVIEW code would blow up during a test that couldn’t be repeated. Instead of rebuilding their systems from scratch, which would have taken their test systems down for a costly amount of time, MGI reused as much of the existing LabVIEW code as possible by just chasing down and fixing the bugs in the old systems. Regarding HTSI, was the code written so far worth saving? In this case, no. It was better to start from a proven architecture, one that MGI has used on multiple real-time projects. The next issue: How to reliably collect real time data from high speed rotors while in flight.

Rotor Box

Once Dick Meredith had attached his strain gages to the rotor, he knew he needed a reliable way of reading their signals and getting them into the cockpit where they would be merged with the airframe measurements and stored for later analysis. He decided to use a PXI/SCXI combination chassis mounted to spin exactly over the center of the rotor. The chassis would run LabVIEW RT for extra reliability, and communicate via Ethernet with a second chassis running LabVIEW under Windows in the cockpit. For MGI, the dual LabVIEW architecture was one we were familiar with from three earlier projects: canceling the wave motion of a ship mounted drilling rig, remote controlled electrochemical cutting of explosive filled shells, and measuring rock strength during controlled crush tests. David chose to base the HTSI program on the software used on the ship.

Reuse Tool

Normally, creating an old program based on a new one in LabVIEW is inefficient, but MGI has developed a free tool that helps you easily and quickly rename a whole set of VIs and type definitions while maintaining their relationships. This works because MGI plans for reuse: we employ the same prefix in the name of all VIs in a project. What’s more, MGI has also developed a free tool for updating the icons of the renamed VIs.

The Success

It only took about a half day to rename the old project and replace elements that were specific to the old project with elements specific to the new one. Next, MGI had to add the key new feature, integration of remotely collected data with locally collected data. At 1.5 days in, David was ready to try out the new application. On the third day, the real fun began—we discovered that the drivers weren’t installed correctly and had various bugs. Because MGI is experienced at debugging our software, the drivers, and your hardware, all at the same time, at four days, it looked like everything was working correctly. We were close, but a second short trip was required where we rolled back to older drivers and just let the “real-time” system run under Windows. Bottom line, the system worked, the test flights were successful, and MGI’s firefighting skills kept HTSI’s firefighting skills online.