HOME

UP

ELECTRICAL ENGINEER: Parker Hannifin - 1986 to 1993

I worked as an electronics engineer for Parker Hannifin Corporation in Irvine, California from 1986 to 1993.

I started out at Parker as a senior engineering technician working for the central engineering department. Parker had over a hundred divisions at the time, and central engineering was created as a tiger team to solve engineering problems that the local divisions could not handle. We had an embedded software expert, a finite element analysis expert, a composite materials expert, an optics expert, etc. - mostly PhDs from MIT, Cal Tech, and Harvard. I was the designated expert on PC hardware, low noise analog, analog to digital conversion, and was one of the members of the servo systems team. My starting title was senior engineering technician, and I later accepted a position in the aerospace hydraulics division as electronics engineer. After a few successful designs, I was promoted to senior project engineer and given responsibility for creating test fixture electronics. I completed far too many projects to list here, so I will just list a few highlights;

Electrohydraulic actuator electronics.

This system consisted of three actuators and three electronics packages. The idea was to have triple redundancy of the actuators that controlled the airplane's control surfaces. Each electronics package would evaluate the other two and vote on shutting down any actuator that stopped responding. In addition, any two actuators working together could drag the third along no matter what it tried to do.

My first task was to solve the following problem: We had ten sets of hydraulics and electronics. Three were at one airplane manufacturer, three were at another airplane manufacturer, three were at Parker for tests requiring three actuators, and one was at Parker for tests requiring one actuator. Whenever a customer had a problem, someone would grab one of the Parker units and ship it to them while the customer shipped the problem unit back to Parker. All of the electronics boxes looked alike and had no serial numbers or history of modifications. While these electronics packages were being shuttled back and forth, there were seven engineers and a roomful of technicians making hardware and software changes. We had undocumented variations in hardware, software, and programmable logic. All of this would be fixed when we left the prototype stage and started building production hardware - if we got that far without the project being canceled. Some of the best engineers in the world had managed to create a system that did not perform to the customer's expectations of reliability and consistency. The project was in trouble, and I was told to do whatever it took to fix the problem. I came up with a solution, made sure that I had the full support of management, and successfully solved the problem. Here is what I did:

I created a master set of schematics, a master copy of each piece of software and a master list of all programmable device files, and made working sets for each engineer. Any engineer could make a change to any hardware or software, but only if he signed and dated the change on the documentation change request copy of the printout or schematic. Any changes made but not documented were removed and the system was restored to the master configuration. I serialized all ten systems and started bringing each into conformance with the master documents. After the first four were made to match the documentation and tested, I swapped them with a customer's units and brought the returned units into conformance. Soon everything was at the same revision level. I kept a detailed log of everything that was done to each unit, what problems were found and the revision level of each of the ten units. I started using a different color of wire for jumpers that undid previous cuts, putting a dab of neon orange Glyptol by each cut, making the jumpers run the same way, and documenting all of the jumpers, cross-referencing them with the schematics. I made a rule that no removed part would ever be replaced - a new part from stock must be used instead. I also enforced use of wrist straps and other anti-static protection, made sure that all electronics modifications to customer units were all performed by a technician certified in military specification soldering, and that all mechanical modifications to customer units were done by a certified airframe and powerplant mechanic. The result of all of this was a smoothly operating system, happy customers, and a successful project. This project didn't use my technical knowledge; we already had a staff of very highly skilled engineers who were making good technical choices. We didn't need technical skills; we needed was to be organized.

Automated actuator test system.

This system tested an actuator with a mechanical input. Mechanical input actuators have a small control arm that can be moved with fingertip pressure. When the input arm is moved, a large hydraulic piston follows the movement with several tons of force. This actuator was to control the flight surfaces of a C17 military transport jet, so fast and responsive movement was very important. The test that insures fast and responsive movement is the phase lag test. In the phase lag test, we moved the input arm in a sinusoid and measured the motion of the hydraulic cylinder. At slow speed, they matched exactly, but as we moved the input arm faster and faster the cylinder started falling behind. My job was to measure this lag with an accuracy of +/- 0.1 degree. This presented a problem; at the speeds we were using the output was distorted as well as lagging. The input was a near perfect sine wave, but the output looked like Gumby's head. The rise had an oscillation superimposed on it which caused it to cross zero several times per cycle and the top of the waveform was severely clipped with the flat top tilted by secondary slew rate limiting. I could get answers that varied by 20 or 30 degrees depending on whether I measured zero crossing, highest peak, center of area under curve, etc. To make matters worse, each run would vary by about two degrees even though nothing changed. My job was to devise a way to get an accurate phase reading from this distorted waveform. My design would be reviewed by a group of consulting physicists working for the military, and that whatever approach I chose had to run on an 8051 Microcontroller. Here is the technique that I decided to use:

First, I measured the input and output waveforms and ran them both through the same software. This decreased the chance of the software introducing errors. Then I calculated a Fourier transform on each signal. I discarded all harmonics, leaving only the fundamental. Then I did a reverse Fourier transform to change the signal back from frequency/amplitude to time/position. At this point, both waveforms were perfect sine waves, and all of the techniques mentioned above gave the same answer. The variation between runs dropped to 0.2 degrees, which is about what I expected the actual actuator variance to be. When the military reviewed my design, the physicists said that, in their opinion, this was the optimum method for determining the phase lag of highly distorted waveforms.

Digital load-curve generator.

One important part of aerospace actuator testing is life testing. Life testing involves running an actuator 24 hours a day under the same conditions that it will experience in the airplane. One of these conditions is the load (resistance to movement), which varies according to the position of the flight control surface as it interacts with the wind flowing past the airplane. For years, Parker had used load curve generators that consisted of opamps and trim pots. The engineer could adjust the height and slope of up to eight segments, thus approximating the desired curve. As the specifications got tighter, the old load-curve generator with its fixed segments couldn't do the job. I was given the task of designing a modern replacement for the old system. Here is the approach I decided on;

First, I sent the analog position signal to a 16 bit analog-to-digital converter. The 16 digital outputs from the converter connected to the address lines of a pair of 64Kx8 EPROMs. The 16 data lines from the EPROMs connected to the digital inputs of a 16 bit digital to analog converter. An 8051 running a six-instruction assembly language program handled all of the timing for all of the chips. (They say that no program that does useful work is ever bug free, but I think that this one was...) The result was a curve of 65,536 points, each settable to 65,536 different load values. Of course nobody wants to enter 65,536 values in by hand, so I wrote a program that did a curve fit on as many points as the engineer chose to enter. This worked well and the system is still in use today.

During the early '90s, Parker had massive layoffs in the aerospace sector. In 1990, my department had five electronics engineers and two technicians. During each layoff, we laid off workers until, in 1993, we had one technician and one engineer - me. I was the last electronics engineer to go, which says something about my value to Parker.