A self-described “river rat” during his teenage years, Herbert B. Voelcker grew up in the small town of Tonawanda, NY, just north of Buffalo, where as a young man he grew to love the water, boats, and steam engines. His early fascination with how things worked eventually led him to study mechanical engineering at the Massachusetts Institute of Technology (Cambridge, MA), and to embark later on a greatly varied technical career highlighted by his research into the mathematical foundations for 3-D solid modeling. Voelcker’s research team, first at the University of Rochester (Rochester, NY) and later at Cornell University (Ithaca, NY), established the mathematical basis for describing 3-D parts. It was one of five research teams worldwide that worked on early solid-model research, and his team contributed significantly to what became the basis for the solid modeling employed in today’s CAD/CAM design tools.
After graduating from MIT in 1951, during the Korean War, Voelcker joined the US Army and served initially with an Army Airborne unit. The Army sent Voelcker to graduate school, where he earned a master’s degree in electrical engineering. He left the Army with the rank of captain after serving seven years, and spent his next five decades in academia. His wide-ranging career has included research in radio propagation, aural perception, and bandwidth compression in the 1950s; modulation theory and digital signal processing in the 1960s; computer science/solid modeling in the 1970s; machine tools and NC programming in the 1980s; and parallel computation, dimensional tolerancing, and mechanical design in the 1990s. His current focus is on variation control in mechanical design and manufacturing.
Today, Herbert B. Voelcker is Charles Lake Professor of Mechanical Engineering, Emeritus, at Cornell’s Sibley School of Mechanical and Aerospace Engineering. Professor Voelcker, who is 79, has taught engineering at Cornell for the past 22 years, and while now essentially retired, continues to teach occasional engineering courses at the university. In an exclusive interview with Manufacturing Engineering, Voelcker discussed his life and work in manufacturing research.
Manufacturing Engineering: What piqued your interest in engineering?
Herbert Voelcker: I grew up in Tonawanda, notable because it’s at the terminus of the Erie Canal. My Irish grandfather ran a ship chandlery there, and my German grandfather ran a brewery. Both died before I was born. The chandlery outfitted ships for the Great Lakes, and my mother had three ships named for her. I had a relatively comfortable rearing, and started building things from an early age, with Lincoln logs and an erector set. By the time I was 11 or 12, I was making my own gunpowder and small cannons. Kids did dangerous things then. I cast a lot of lead soldiers, and I still have lead burns on my legs, from the ladles tipping.
ME: So early on, you tinkered with all sorts of things, like steam engines, and building sailboats?
Voelcker: Yes, I loved steam engines. My father taught me how to build sailboats. I built a fourth boat about 10 years ago. I was called a ‘river rat’ in my teens. We hung out on a dangerous stretch of the Niagara River, about five miles above Niagara Falls where the current is swift. We sailed on the boats we built there, and we needed fast boats because of the current. The combination of building and boating led to an early desire to go to the Naval Academy, but I couldn’t pass the vision test.
ME: Did you always want to be an engineer?
Voelcker: Not necessarily an engineer, but without ever consciously thinking about it, I knew I would be involved with technology, in one way or another, for the rest of my life.
ME: What was it like attending MIT?
Voelcker: Well, in current jargon, I learned how to ‘game the system’—how to get homework done efficiently, how to pass quizzes, and all that stuff. I graduated from MIT with very high grades, but the relationship with MIT was almost adversarial—an excercise in survival. I stayed sane by pouring any excess energy into lightweight crew—I rowed stroke for the varsity—and captaining the rifle team. In later years, when in the Army, I shot high-powered rifle in the 1956 Olympics.
I got through MIT with strong colors, but on graduation day in 1951, I sold all my books, because I had decided I had not been well-educated and did not want to do engineering. I had two choices: go to Harvard Business School, where I’d been accepted, or go into the Army. I’d been offered a commission in the regular Army, and there was a war on, so I chose the Army. It was a good decision. I was in the Army for seven years, and resigned as a captain. I spent the first couple of years as a signals officer with an airborne infantry unit. The Army then decided I should be an electrical engineer, and sent me to graduate school at MIT to study electrical engineering. That was hard because I didn’t have the background, but I did earn an MSEE and spent my final years in the Army at the Signal Corps R&D lab in Fort Monmouth, New Jersey. I was with a very good mixed group of military and civil-service engineers, who taught me lots of basic engineering. I decided then that I really wanted to do engineering, and probably engineering research, and that I couldn’t stay in the Army, because the Army quite rightly holds that career officers should be generalists, not specialists.
ME: What was your next move?
Voelcker: In 1958 I won a Fulbright Scholarship, and went to England to study with Colin Cherry, a professor of electrical engineering at Imperial College. I was a lecturer in electrical engineering at Imperial College for the last year, and my first research there was on human perception of speech. After that, I entered into about 10 years of work on what’s called modulation theory. This is how you transmit radio waves and television signals, how you put information on carrier waves—amplitude modulation, frequency modulation, phase modulation, pulse-code modulation. I won prizes for that work, and patents related to signal processing.
ME: How did you get involved in solid modeling?
Voelcker: By 1966, I had decided that digital computers were not going to go away, and that I simply had to learn about them. I’d avoided it. People tend to avoid things that are scary, new, powerful, and require a lot of conceptualization, and so I decided just to face this. I had a year of academic leave time, and I went back to Imperial College and spent that year programming and studying digital signal processing. But by about 1971, I got bored with digital signal processing, because I thought the main problems had been solved, and I looked for something new to do. I was then 41 years old, and I wanted to do something important. So I spent about a year poking around in parts of technology I knew something about. In 1970-1972, I flirted with computer science, but backed away to look for something grittier. This led me to the interface between computation and mechanical engineering and automation, which was just beginning to be thought important.
ME: And you ended up in automation engineering?
Voelcker: Yes, and then the question was, well, what does that mean? One interpretation: you should be able to go from a concept, a design concept, into some sort of finished good or product or part. How do you do that? Well, you need ways to direct machine tools automatically, and have programs smart enough to figure out what the machine tool ought to do to realize some concept. While these ideas were beginning to be talked about then, no one had any idea of how to put mathematical or physical substance behind them. They were just airy-fairy ideas. So we simply said, ‘Let’s dive in. Let’s try to write some software to drive machine tools and make stuff!’ And this led us into studying the numerical control technology of the time.
ME: Describe how solid modeling research came about.
Voelcker: It became clear in 1972 that we couldn’t automate anything until we could describe mechanical parts and assemblies unambiguously in computers. We knew, but a surprising number of working engineers did not know, that drawings and ‘wireframe’ CAD were not unambiguous. So we focused all of our effort on what came to be known as solid modeling. At the time there were about five groups working from the same starting point, and all came out in the later 1970s with different answers, which is pretty interesting. The groups were ours at Rochester, Charles Lang’s group at Cambridge University in England, a group at Hokkaido in Japan, another at TU Berlin, and a fifth at Sandia Labs. The Rochester and Cambridge groups produced workable, ‘revolutionary’ systems—PADL-1 and Build-1 respectively—that were very different internally and incompatible. The other groups did useful things but gradually fell by the wayside. The Rochester group, I think it’s fair to say, laid the scientific foundations for the field. The Cambridge group was more ad-hoc and focused on very clever algorithms. The Cambridge work was commercialized within about five years, and it now is the basis of one of the major industrial CAD/CAM/CAE systems in the world.
ME: What were some of the technical difficulties, which were immense, in terms of computational demands?
Voelcker: Ah, computational intensity! Solid modeling uses very large computer resources, so the early systems tended to be slow, or they could not deal with realistic-sized problems. Trying to cram a whole engine assembly into a solid modeler of the 1985 vintage was basically impossible.
ME: What happened after solid modeling arrived?
Voelcker: The spin-off of solid modeling was quite interesting. We knew by about 1976 that we had basically broken this problem, and we had a demonstration system called PADL-1. PADL means Part Assembly Description Language. It was a little toy system, but it was a beautiful toy! It worked exactly correctly, always. You could learn to use it in about 20 min; it was a command-driven system that could display and compute the mass properties of simple parts. It didn’t do anything like drive an NC program. It was just a descriptor, but it proved conclusively that the program knew everything about a part, and in principle could compute anything that was computable about that part. Unfortunately, PADL-1 was not flashy enough to draw in commercial developers, so we decided to launch a larger, industry-collaborative project called PADL-2.
For PADL-2, we pulled in 10 sponsors including Ford, Boeing, Sandia, and CAE vendors. The whole idea was to get powerful users, like Ford and Boeing, and competent vendors working together on the same body of software, and maybe the thing would go. And that seemed to do it, because Unigraphics, a sponsor, did adopt, improve, and commercialize the system as Unisolids. General Motors used the algorithms, which they got from PADL-1, in a system called GM Solid, which for about four years was a primary design system. Overall, the PADL-2 project, which ran for two years, was a major strain on us, because we redeployed a lot of manpower from research to software development. But it did the job—it kicked the principles and the algorithms out to the world.
ME: So few potential users adopted the system?
Voelcker: GM used the principles and they certainly used the algorithms. Ford, Sandia, and at least a dozen other companies did some serious experimentation; how much PADL code they used, we never knew. But the real break was getting the Unigraphics people to develop and commercialize the system. They abandoned the PADL-2 core after about four years, but it got them in the market and established them as solid modelers. Other vendors, most notably Autodesk, adopted the PADL-2 core for commercial use later in the 1980s. PADL-2 principles, such as CSG [‘constructive solid geometry’] classification algorithms, are very widely used today in the research community.
ME: When did you start on automation engineering?
Voelcker: In 1982, we finally had a strong enough part modeler to allow use to return to our original goal—automating manufacturing, and specifically NC. So the next order of business was learning modern CNC technology and establishing a CNC lab. I had been away from machine tools for 30 years, and so much to learn: which machines and what tooling to buy, and much more. I had to convince the university to make new basement space available, put in a proper concrete floor, and so forth. The NC language standard RS-274, which covers M-codes and G-codes, became our bible, but we found NC technology to be pretty messy because it grew up before computers. If NC development had been delayed 10 years, it would have had the benefit of early ideas in programming languages, and that would have made learning and using NC easier. When we had facilities and some basic machining experience, we focused on two related problems: automatic NC program verification, and automatic programming at the unit-operation level, the MPL project.
ME: You developed the Machining Process/Programming Language [MPL]. How was that similar to the Automatically Programmed Tool [APT] language developed by Doug Ross?
Voelcker: They were very different. APT was designed to solve the difficult problem of driving NC machine tools to make what are called sculptured surfaces—airplane spars, turbine blades, things like that. You chuck up a cutter in a five-axis mill and you may machine for days to produce these complicated parts. MPL was to do something quite different. It was to work in multisetup machining operations to make typical ‘prismatic’ mechanical parts—not fancy parts like turbine blades—but parts in which you have to do some drilling, reaming, and 2½-axis milling in several setups. MPL let you define the setups, such as clamping operations, and unit operations—rough a pocket, contour a profile—and did all the low-level scutwork, such as cutterpath planning.
ME: Tell me about your current focus on Geometric Dimensioning & Tolerancing [GD&T] problems.
Voelcker: I’m interested in variation control, which is central to all kinds of things. In mechanical design, dimensional variations are controlled through geometric tolerancing, which is an untidy technology. Geometric tolerancing was invented in World War II, and it has taken a long time to gain acceptance. The newest version of the American standard, ANSI Y14.5M-2009, is five years late and it still contains some gaps and inconsistencies. The problem is that GD&T lacks a rigorous mathematical foundation: it grew up from the shop floor. The main ideas are surely right, because things get built and fit together, but training people to use it is difficult. If you go ask someone in manufacturing ‘What do you think of GD&T?’ you’ll probably get an earful. The challenge for people like me is to find mathematical principles underlying GD&T’s rather ad-hoc principles!
ME: What do you see for the future of US manufacturing?
Voelcker: I believe there will be manufacturing in this country indefinitely: manufacturing employment will continue to decline, but the produced value will increase because the products will be increasingly highly engineered. There are parallels with agriculture here. But let’s step back and ask a deeper question. Men have made things for thousands of years by artisan methods: make parts one by one, and ‘file-and-fit’ the parts to assemble the product—one copy at a time. Two hundred years ago, we had two revolutions: mechanization, and interchangeability, with interchangeability being the profound break with the artisan past. But might there be other, perhaps better ways to do business? What about replacing interchangeability with ‘compliance’—the notion that parts in assemblies are made simultaneously and need only work together within that assembly? That’s how our bodies.assemblies of joints, links, pipes—are made, and that’s how assemblies are made in some new rapid prototyping [‘layered’] manufacturing processes.
This article was first published in the July 2009 edition of Manufacturing Engineering magazine.
Connect With Us
