Pump Virtually Gets its Shaft

When a colleague uses the word "camshaft" in a conversation, it's unlikely a field-programmable gate array (FPGA) chip will come to mind. But the combination of an FPGA chip and software recently produced a virtual camshaft that worked successfully during development of a small high-speed hydraulic pump (see photo above). Active Signal Technologies (Linthicum, MD), a small materials-research consultancy, developed the pump and Mink Hollow Systems, (Highland, MD), a system integrator, produced the virtual camshaft software.

Because mechanical check valves couldn't operate fast enough in the new pump, the designers at Active Signal took advantage of an active-valve design previously developed at Moog (East Aurora, NY), a company that provides hydraulic actuators for aircraft. The valve includes two concentric cylinders, each with six holes or slots (see rotating inner cylinder figure on next page). During a 360 degree rotation of the inner cylinder, the valve opens six times as the holes coincide. A small high-speed electric motor rotates the inner cylinder and a 9-bit shaft encoder feeds position information to a data-acquisition (DAQ) system, essentially a virtual camshaft, that controls the pump's electrically-driven piston (see diagram right). (The pump has both an inlet and an outlet valve, but to simplify the discussion, we will describe the operation of only the outlet valve.)

In the time between each alignment of the slots, the pump piston goes through a complete cycle. Thus, the pump piston operates at six times the rate of the valve's rotation. The DAQ system must carefully synchronize the pump piston with the valve position. Setting the speed of the valve's motor establishes the actuation rate for the pump piston, through the virtual camshaft.

As the valve rotates, the DAQ system moves the piston rapidly through a series of small position steps that produce the maximum possible pressure as the outlet valve opens. These steps could represent a square, triangle or sine wave (see timing diagram next page), depending on the required pump performance. As if coordinating the valve's position with the piston strokes wasn't enough, consider that the prototype pump's piston operated from 2000 to 5000 strokes per second. (see sidebar below, "How the Pump Works")

In the prototype setup, the host PC would start the pump in a synchronized fashion so the pump piston properly tracked the position of the rotating valve. But, due to timing limitations within the PC and its software, the DAQ system could not acquire all nine bits from the position encoder. The pump developers had to settle for only the encoder's least significant bit (LSB), which produced 256 pulses per rotation. So instead of a virtual camshaft based on absolute positions, the system operated on 256 pulses per valve rotation, or a relative-position indicator of valve position. A few extra pulses due to noise, or a few pulses missed by the software, and the piston-valve synchronization ended.

To get the virtual camshaft working properly, Drs. Arthur Cooke and Keith Bridger at Active Signal Technologies worked with Eric Lyness at Mink Hollow Systems. Lyness, a LabVIEW Architect, decided to implement the digital control loop in an FPGA chip, which would improve control-loop response time. In addition, the speed of the FPGA chip would provide enough time to acquire and process all nine bits from the shaft encoder. As a result, the new control software could operate on absolute-position information.

Active Signal Technologies had already purchased a PXI-based DAQ system, so Lyness simply bought an add-in PXI FPGA-based board and LabVIEW FPGA. After working with the software and the prototype for about a week, he had the pump operating properly. Because the software would now read the 512 unique codes, rather than just 256 pulses, for each valve rotation, Lyness could measure absolute angular position to 1 part in 512, or 0.70 degrees. Based on one valve-open position reading, he could then calculate the codes that would occur at the other five valve-open positions. The FPGA chip's code used the unique position codes to produce the incremental signal that drove the pump piston.

Although the prototype worked well, Drs. Cooke and Bridger wanted better resolution for the waveform applied to the piston actuator circuit. For each rotation of the valve cylinder, the pump piston went through six cycles. Thus each piston cycle could have only 512/6, or 85 unique values. So, when the software applied a sine wave to the piston-control circuit, it had to produce the sine wave in 360 degrees/85 steps or 4.2 degrees/step. Cooke and Bridger aimed to achieve a resolution of 1 degree/step for the piston-actuation waveform.

Lyness obtained additional resolution by taking advantage of the FPGA chip's internal timing. At a valve speed of 500 rps, for example, the LabVIEW FPGA code ran fast enough to go through as many as 200 cycles between encoder increments. So, Lyness added code that counted these cycles and then divided the accumulated value by 4, which would yield two extra bits of resolution (22 = 4).

"Say the FPGA chip counted 180 steps between encoder increments," said Lyness. "Dividing 180 by four yields 45, so between the next two decoder valve changes, we waited 45 cycles and incremented a 2-bit count, waited another 45 cycles and incremented the count again, and so on. We reset the 2-bit counter and performed the division again after each encoder increment to keep the piston synchronized with any change in the valve's speed."

Combining the 9-bit decoder value with the two-bit software count obtained between each change in decoder output provided an overall 11-bit resolution, or 2048 codes, for each valve rotation. That value translated to 2048/6, or 341 codes per piston cycle for a resolution of just over one degree. "The calculations took place so quickly that we never saw any change in synchronization as the valve motor accelerated or decelerated," added Lyness.

"We thought about creating a look-up table of sine values in the FPGA chip," said Lyness. "That way when we detected a small synchronization error, we could adjust the sine values and write new data into the table. But it takes too much time to download that information into the FPGA chip."

Lyness acknowledged it took a few days to learn how to develop code for an FPGA-based application. "Here's an example of a simple trap I fell into," explained Lyness. "I set up a 512-element array of sine-wave values. When the FPGA code didn't finish compiling after several hours I discovered I shouldn't design an FPGA-based application that contains an array with more than 32 elements." In the end, Lyness used high-speed memory on the FPGA board and included a simple read/write loop in his software to access the external data from within the FPGA chip's code.

The next time you hear the word "camshaft," FPGA chips still may not come readily to mind. Just remember, though, the combination of high-speed digital processing and software can often solve problems where mechanical devices don't stand a chance.

Reach Contributing Editor Jon Titus at jontitus@comcast.net .