Quality Magazine

CMMs: The Drive for Communication

May 19, 2003
Incompatibility among different brands of coordinate measuring machines (CMMs) and other metrology systems costs American business an estimated $1 billion each year.

But now, thanks to growing momentum behind an industry effort to cut down on CMM programming costs, factory executives are hoping to take a big bite out of that total.

In an initiative driven by heavyweight manufacturers including Ford, DaimlerChrysler, Boeing, Caterpillar and the U.S. Navy, a newly formed consortium is stepping up efforts to develop a "common driver" that would eliminate the need for multiple inspection programs written in proprietary CMM languages.

When this driver is finalized and tested by the consortium--which includes participation by CMM vendors--it would mean that an inspection program written for one CMM could be used on any other CMM, regardless of the make or model.

No one around the effort is willing to say when this common driver could be ready for use. But given the current pace of activity, some time during 2002 seems a reasonable target. And the effort seems certain to be pushed hard by Ford and other big CMM users, whose complaints about CMM incompatibility appear to have grabbed the attention of vendors.

Because of the current requirement to write separate inspection programs for each line of CMMs, based on each vendor's proprietary approach, CMM users face excess costs on a variety of fronts. Manufacturers that use many different brands of CMMs must store versions of these critical documents for each type of dimensional measuring machine. For a company with thousands of measurement programs, storing, retrieving and updating these documents amounts to a massive and expensive undertaking.

In addition to the document control issues, critics say that use of proprietary languages requires additional worker training and slows time-to-market. Further, the need to rewrite code, or worse yet, to rely on incomplete translations of inspection programs moved from one CMM to another, opens the door to potential inaccuracy. In theory, the common driver would close this door.

When completed, the common driver would be an interface between the task programs developed by manufacturing personnel and the machine instructions used by each CMM to carry out its individual inspection routines. The common driver would allow the same task programs to operate on multiple vendors' machines, as opposed to today's need to program, train, and store inspection programs based on each CMM's proprietary programming systems.

Dollar drain
There is no doubt that system incompatibility is a major cost factor for CMM users, says Walter Pettigrew, chairman of the Metrology Automation Association (MAA). The industry group pushes for an open architecture environment and has set up a committee to develop a common driver.

Ford, for instance, uses many types of CMMs at its U.S. and international factories and is forced to use different programs from machine to machine. The automaker was recently burned by incompatibility issues to the tune of $10 million a day while programmers worked to clean up program code, says a Ford representative. Problems surfaced when a measurement program developed in the U.S. on a Brown and Sharpe CMM couldn't be used on a Zeiss CMM in a European facility.

"Every metrology user suffers from the same problem," notes Robert Waite, Advanced Metrology Group manager at Daimler Chrysler Corp. "My (CMM) problems are the same as Ford's. We want plug and play architecture."

Waite, in a September 2000 white paper, "(The) Need for a National Metrology Testbed," points to a number of "failures to achieve an efficient metrology process." Waite says: "There are islands of metrology systems that stand as a symbol of yesterday's technology, each configured with a series of proprietary interface technology. Each unique system has incompatible controllers and software applications."

These islands mean that operators trained on one CMM cannot necessarily operate a different CMM in the shop. He adds that this system of proprietary software has led to the need for redundant measurement programs that are recreated manually at each stage of the process to monitor or validate product or process quality.

Perhaps the most egregious complaint Waite levels against use of multiple languages is the impact it has on measurement accuracy. "CMM operators recreate inspection programs using ambiguous measurement practices at each stage of the product development cycle. Each program provides a slightly different answer for the engineer, who wonders which answer is correct," Waite says.

Currently, there are exchange protocols such as the Dimensional Measuring Interface Standard (DMIS). However, Christopher Garcia, president of Xygent Inc. (North Kingstown, RI), a software company spun off from Brown and Sharpe, says that "at best, a measurement program translation (using DMIS) is 75% to 85% complete, while 50% or less of complex programs may translate."

In theory, a common driver would eliminate translation problems, while at the same time paving the way for third-party software developers to generate new capabilities based on this open architecture. In an open-architecture environment created by standardizing CMM interfaces, new products could more quickly be brought to the marketplace.

Busting barriers
Driving this effort to develop a common driver is a group called the Metrology Interoperability Consortium, formed by various end users, vendors and the National Institute of Standards and Technology (NIST). This group met at Quality Expo International in late April, and again a month later, to agree to work on this effort.

"The goal is to eliminate data roadblocks," explains Albert Wavering, Group Leader, Machine Group, at NIST. By breaking through productivity obstacles created by proprietary approaches, the group hopes to reduce product development cycle time, eliminate redundant programs, eliminate proprietary interfaces, improve products and decrease training expense, Wavering notes.

One potential stumbling block for the consortium, however, could be vendor concerns about sharing technology with competitors. According to the consortium agreement, "technology" includes the entire body of technical knowledge, methods and materials generated during development of the common driver.

The MAA formed the Common Machine Interface (CMI) initiative with the idea of developing protocols by October. The interface, which is another name for a common driver, is based on the collaborative efforts by CMM manufacturers Brown and Sharpe (North Kingstown, RI), Carl Zeiss IMT (Minneapolis) and LK Metrology (Brighton, MI). The companies initially have focused their efforts on the basic instructions for touch-probe CMMs. These straightforward instructions direct the probe to do such tasks as return tool, pick up tool, and process dozens of other commands.

"A lot of work has already been done, and that is why I don't think it will take long to get this (CMI) finished," says Donald Vincent, executive vice president of the MAA. "They don't have to start from a blank piece of paper, but just take the work they have done and make use of it. There had to be some proprietary information considered as they got to this point. Maybe that is behind us and that is why it will go faster."

Chairing the CMI coordinating committee is Neal Laurance, Ph.D., a retired Ford Motor Co. scientist and a Life Fellow of the Institute of Electrical and Electronics Engineers. Dr. Laurance says the group will coordinate with NIST, as well as with I++, a consortium of European auto manufacturers that is also working on a CMM common driver. "The goal is a specification that offers global savings," says Dr. Laurance.

Test bed needed
To help develop, test and verify that a common driver works, the Metrology Interoperability Consortium is working to establish a National Metrology Test Bed. This test bed would be a mechanism for testing interface specifications and implementations. It would call on the consortium's diverse membership of CMM users and builders to jointly develop interface specifications and conduct pilot programs to share test procedures, tools and data to establish conformance and interoperability. NIST plans to take the lead in developing test methods and verifying results.

While the initial focus is on CMMs, the test bed could also work toward integrating other equipment, something that the MAA hopes will happen. "Our goal is to make it broader than just CMM machines," says Vincent. "We want it to go into other industries and other pieces of equipment in the metrology automation business so that some of the non-contact companies providing equipment will find use for it too. We want there to be an industry-wide guideline."