Americanmachinist 710 Camp0100png00000001352
Americanmachinist 710 Camp0100png00000001352
Americanmachinist 710 Camp0100png00000001352
Americanmachinist 710 Camp0100png00000001352
Americanmachinist 710 Camp0100png00000001352

CAM-powered engine development

Nov. 1, 2002
Software keeps pace with one Nascar team's engine building.

Software keeps pace with one Nascar team's engine building.

Bill Elliott, driver of the #9 Evernham Motorsports Dodge Intrepid R/T, in the pits during the Budweiser Shootout at Daytona International Speedway in Daytona, Florida.

Evernham eliminated square corners in the pocketed areas to improve this fan spacer's design. In this SolidWorks model, the gray areas highlight the complex fillet blending in the radial pockets.

Evernham's GibbsCAM system accurately reads SolidWorks model .

GibbsCAM overlays a CNC toolpath against the solid model of the fan spacer.

GibbsCAM's Cut Part Rendering function visually verifies machining processes, in this case the finish cuts cleaning up after roughing.

On-screen verification lets Evernham quickly load the fan spacer's part program to a CNC machine tool and start cutting.

Even though it meant manufacturing a much more complex geometry, the new design of this fan spacer reduced weight and increased part integrity.

Redesigning and building four new engines a week is nothing unusual for Evernham Motorsports Engine Shop, which supports the Dodge Intrepid R/Ts of team Nascar racers

Bill Elliott, Casey Atwood, and Jeremy Mayfield (plus one test car). Any given week, the team generates data for new engine components using one of several different design systems. But this diverse information has to be quickly and exactly communicated to CNC machines on the shop floor to be of any use. That's where CAM software keeps the team on track.

Evernham typically stocks enough engine parts for six to eight rebuilds (roughly one to two month's supply). When part specifications change, though — and many do from week to week — the engine shop scraps the old parts and machines a new supply. A normal manufacturing run seldom exceeds 60 to 80 parts.

The team decides which CAD system to use depending on the particular type of job. It finds some systems better suited to developing complex surface models, while others are strictly limited to Boolean solids. Some solely generate finished ANSI blueprints.

What ties these programs together into a cohesive whole is a single CAM system that takes part data, no matter what format, brings it into the CNC program, and manipulates it for fast and efficient machining. This interoperability is crucial, according to Steve Oliver, shop manager. "A lot of people only consider interoperability of their system at the design end — being able to bring data into the CAD system," he explains. "For us, that data still has to go to the CAM system where we can create the manufacturing processes, verify them in a computer simulation, and then prove them out on the shop floor with the CNC machinery."

Typically, designers communicate 3D design concepts to manufacturers through a 2D blueprint. The manufacturer then has to re-interpret that 2D drawing back into a full-3D part. Evernham skips these two steps — the blueprint development and the re-interpretation of that blueprint into manufacturing instructions — by taking solid-model data directly into its CAM system and using shop-standardized specifications.

Evernham still relies on blueprints to archive and communicate ideas. But the process of part documentation is no longer a part of the critical path to manufacturing. If the design model accurately depicts the part that needs to be made, then CAM allows the user to accurately recreate that part.

"Once the design model has been read into the CAM system, we have the ability to create whatever tooling we'd like to use to manufacture that part or the option of selecting it from a library of existing tooling," says Oliver. "Then, we assign the toolpath in precisely the manner that we want the part cut and code those instructions for our machine tools on the shop floor."

Evernham's redesign of a fan spacer is an example of how its CAD and CAM work together to reduce product development and production time. The fan spacer, a small part that fits on a shaft, is where the fan blade bolts on. As with any engine component, Evernham's aim is to reduce weight and improve strength.

The engine shop once made this part with square pockets that reduced weight. These square corners, though, created a place for stress to accumulate and fractures to occur. Therefore, Evernham redesigned the fan spacer with complex curves and sculptured areas. The result was a lighter, yet stronger and more durable part.

Previously quite simple from a geometry standpoint, the fan spacer now contains complex radial blends where the surfaces meet. Thus, the CAM program not only needs to interpret the part data correctly but it must also develop a complex toolpath that takes into account tool offsets, speeds, feeds, and finish stock. According to Oliver, Evernham's CAM package does all this, allowing the team to get parts like the fan spacer into its engine configuration quicker than many other teams.

The shop uses GibbsCAM software from Gibbs and Associates, Moorpark, Calif. Says Oliver: "The GibbsCAM system reads part data from any of our design sources, so that instead of spending my time fighting with data translation, I can concentrate on the job at hand. . . making horsepower."

In addition, Evernham gains time by exploiting the CAM system's post-processing capabilities. "I don't have to edit G code," Oliver comments. "I read the part data file, create the manufacturing model, and output code for the machine of my choice."

Translation vs. transfer: Where interoperability meets reliability
To better understand how part data interoperability impacts Evernham's design and manufacturing operations, it's helpful to review the concept of interoperability.

First of all, basic math underlies all design systems. For instance, a simple geometry, such as a line, can be described with two points in space, expressed in Cartesian (X, Y, Z) coordinates. The equation required to describe this line is basic geometry and is consistent in most systems. However, when it comes to describing a complex curve, such as a spline, the mathematical basis becomes more complex, and in some cases, even proprietary.

Obviously, competing software companies don't want to share this information. But this lack of communication between systems leaves users in a bind. After all, how can a spline be described in a mathematically identical way in two different systems when the developers of those systems refuse to reveal to each other how their specific equations work? The simple answer is that they can't.

To some extent, standards like DXF and IGES address this problem. The standards were meant to let CAD users like Evernham effectively translate geometric data between systems. For instance, IGES (Initial Graphical Exchange Standard) was developed as a data format for CAD data. Instead of a single way to create a spline, the IGES standard contains different mathematical descriptions for spline data, each with its own designation, such as Parametric Spline Curve, type 112, and Rational B-Spline Curve, type 126.

The mathematical basis for each of these spline types is published as public-domain data. This lets the developer of "Design System A" create a translation tool that transforms the System-A proprietary spline as an IGES-data type. Inversely, the developer can devise a tool that also reads IGES entities and transforms them in the System-A native format. If the developers of "Design System B" do the same thing, users now have a methodology to exchange complex data between design systems A and B.

There's a shortcoming to all this, though. It's not unusual for the data to change in minute amounts during this transformation process. This alteration is extremely minimal (usually somewhere out at the 13th decimal place) and usually of no consequence. However, the degradation in data quality can take place twice during each translation, once moving the data from the host system to the IGES environment and then again moving from IGES to the target system. This happens again every time the data is translated, an unacceptable problem for most shops, especially Evernham.

In simplest terms, the translation process is like taking a music cassette tape and making a copy of it on a standard cassette recorder, and then making a copy of that copy, and so on. At some point, the original information degrades to the point where the music is unrecognizable.

Evernham takes advantage of another way to move data, known as transfer. This moves the geometry data description into a new format intact with its original mathematical formulas. This is more like making a copy of a computer floppy disc rather than a musical cassette tape. When a copy of a computer disc is made, the data is simply described as a set of zeros and ones. That information doesn't degrade from copy to copy, and, as a result, the 1,000th copy is as valid and fresh as the first. A good example of data transfer happens in solid modeling.

Rather than re-invent the wheel by continuing to develop their own proprietary solidsmodeling functions, most PC-based CAD/CAM vendors license solid-modeling technology from third-party developers. A good example of this is the Parasolid kernel, developed by EDS PLM, Plano, Tex. Instead of keeping its proprietary representations to itself as it developed its solid-modeling capability, EDS opted to create a software toolkit for solid modeling. This toolkit contains all of the necessary functions required to work with solid models. As a result, other CAD/CAM-system developers can license the Parasolid kernel and shortcut their development time to full-featured solid modeling.

What solid modeling kernels allow is System A and System B to use exactly the same representations — if they both license consistent versions of the same solid-modeling kernel. This lets shops — including Evernham — transfer models between the two systems without going through a translation process and without suffering any degradation in quality. In addition, because both systems use the same solid kernel, both systems' interpretation of that data is identical; something not guaranteed with data translation.

There are two major suppliers of solid-modeling kernels worldwide — Parasolid from EDS PLM Solutions and ACIS from Dassault Systèmes, Woodland Hills, Calif. The GibbsCAM software used by Evernham Motorsports licenses and incorporates both of these kernels to ensure solids interoperability.

According to Bill Gibbs, founder and president of Gibbs and Associates, licensing two kernels ensures GibbsCAM covers the greatest span of solid modeling possible, giving customers like Evernham more flexibility for design and manufacture. "This breadth of inter-operability is one of our greatest strengths," he explains. "We don't care where the data comes from, we just want to make sure that our customers can read that data and develop tool-paths for it."

And that suits Evernham perfectly because on any given day, machining data can come from one of many different sources.

If the team can't read this data, it can't machine it. And if it can't machine it, the team won't be using it to win the next race.

Latest from CAD and CAM