INCOVA Technologies manufactures intelligent electro-hydraulic poppet valves and proprietary control algorithms used in off-road construction equipment such as backhoes, excavators and cranes built by JLG, John Deere and others. Before the development of these valves and their controls, equipment manufacturers relied on standard spool valves to operate hydraulic actuators.
An INCOVA electro-hydraulic poppet valve (EHPV) maintains a constant opening, or flow area, proportional to the current command it receives, regardless of the pressure across the valve. According to Corey Quinnell, systems engineer at INCOVA, the company places its valves in an H-bridge configuration similar to that used to control a bidirectional dc motor. "Each proportional valve in the bridge operates independently," says Quinnell. "A traditional spool valve has a fixed relationship between the inlet and the outlet flow area."
"The EHPV lets us independently meter the inlet and the outlet," says Quinnell. "This independence lets us make machines easier to control and more fuel efficient. Each actuator workport — inlet or outlet — has a sensor that measures the hydraulic pressure, a key input to the controllers."
Initially, Quinnell and his colleagues wrote a library of valve-control functions in C and then used an Excel spreadsheet to "line up" the sequence of function calls. An Excel macro then produced the final application code in C. But this slow method consumed too much time and effort. "We needed to minimize the time between developing a controls concept, testing it on a machine, and then analyzing the data to see what went wrong and what worked properly."
"After doing some research, we concluded the combination of Simulink tools and a Speedgoat computer — our real-time target — would give us a way to quickly and easily make iterative changes to control algorithms," says Quinnell. The team used an xPC Target real-time computer from Speedgoat (Murten, Switzerland). Thus, the computer became known within INCOVA as "the Speedgoat."
"Only a few people at HUSCO, our parent company, used The MathWorks Simulink software and none of them had experience using Simulink they way we intended to," says Quinnell. "We took advantage of The MathWorks' support team as we worked with Simulink. We knew our goal and it was just a matter of 'How do we get there?'"
As a proof of concept, the team took simple control functions, modeled them in Simulink, and ran the models with test vectors to check them. "When we started we just wanted a joystick value to go into the Speedgoat and another value to come out — nothing complicated," says Quinnell. "After confirming that our real-time computer handled the joystick information correctly, we moved on to test basic control functions on the Speedgoat. Again, we knew the joystick values going in and could match the computer's outputs with what we expected from the control algorithm. That's how we verified the control functions worked properly."
After the team better understood the capabilities of Simulink, it created new control functions and test vectors to use for simulations. "We used Excel to create the test vectors and brought the vectors into MATLAB so Simulink could read them and 'play' the test vectors through the simulator," says Quinnell. "We used Excel so we had a known-good baseline against which we could verify the new control functions. The simulation outputs should match those in our Excel document. After we verified the models worked properly, we used Simulink to create the C source code. We then compiled the code and put the executable program into the Speedgoat that sent flow commands to our EHPVs on a prototype machine."
"When we first used Simulink, we created a large 'flat' layout and we couldn't easily find thing on it," says Quinnell. "So we created separate Simulink subsystems for machine inputs, controls, machine outputs, machine initialization, data acquisition, constants and so on. This was part of our learning process. The organizational aspect of Simulink made a 'design' easier to read and understand."
"We also set up our own design rules and applied them to our Simulink controls model," says Quinnell. "This 'coding' standard made it easier for everyone to understand the model. We also used color codes to differentiate between inputs, outputs, constants and so on."
Creation of easy-to-maintain control functions within Simulink quickly became a goal for Quinnell and the team. "We defined functions that encapsulated only one task or idea and then used multiple functions in series or parallel to translate a joystick command into a valve-control command. New function blocks became part of a library that we will reuse in new applications."
"Here's an example of a function block," says Quinnell. "Suppose an operator tries to move a piece of construction equipment in a way that requires more hydraulic-fluid flow than the pump can provide. In that case, a function block translates the operator flow commands (function inputs) into valve-control commands (function outputs) to reduce the flow to each actuator and thus match the flow demand with the pump's capability."
Quinnell noted that as the team became more proficient with Simulink, the way team members handled design constraints and their ideas about how the models worked evolved. Thus the library of function blocks changed as the team continued to refine the controls concepts.
Although INCOVA uses a Speedgoat computer for testing, it uses its own controller in commercial equipment. "During development and rapid prototyping, we use the Speedgoat to do all the math involved with the control algorithms," says Quinnell. "This rapid prototyping arrangement sends a CAN-bus message with numeric results to our controller that converts the numbers to an electric-current value." Each valve controller provides four independent current sources for the EHPVs. In a commercial product, the INCOVA controller handles all control operations, pressure-sensor reading, current drivers and CAN-bus communications.
Team members include Quinnell — a computer engineer, two electrical engineers and a mechanical engineer. "We are all well rounded — that's the best way to portray our team," says Quinnell. "We know about mechanics, electronics and hydraulics, so we can speak the same 'language.' When anything new comes along, everyone gets up to speed quickly."
One added benefit of using Simulink: A dramatic decrease in total development time. The original process for prototyping new controls required repeated hand offs between application engineers and a dedicated software group. By using Simulink, the application engineers can do the majority of the day-to-day prototype work themselves.
for a larger version