Quality Digest      
  HomeSearchSubscribeGuestbookAdvertise October 28, 2020
This Month
Home
Articles
Columnists
Departments
Software
Need Help?
Resources
ISO 9000 Database
Web Links
Back Issues
Contact Us

by Dirk Dusharme


The much-maligned Bill Gates had it right. It's all about the software. While Big Blue placed its bet on hardware, Gates and company laid the foundation for computing software that eventually transformed the information world as we know it. Understanding what Apple did not, Microsoft ensured that anybody could easily get into and out of its operating systems, an open architecture that freely let any kitchen-table programmer write applications that could tie into Microsoft's operating systems and have access to any other hardware or software running under that system.

This kind of accessibility so pervades our culture that industries seemingly far removed from information technology expect and increasingly demand plug-and-play compatibility. Even in the relatively small market of dimensional measuring equipment software (in particular, the software used to control, collect and analyze data from coordinate measuring machines), customers are pushing hard for open standards that allow PC-like plug-and-play compatibility.

For the past 20 years CMM customers --largely in the automotive and aerospace industries --have been pushing for an open standard --software, hardware or both --that would allow different brands of CMMs and CMM software to share data. Although seemingly good for the customers, this type of compatibility makes CMM producers cringe even while they give in to customer demand. At stake is competitive edge and, as one CMM manufacturer put it, fear of "the commoditization of CMMs."

The problem

It isn't always easy or even possible to make a measurement routine written for one brand of CMM work exactly the same way, or at all, on a different CMM using different software.

As more companies look to upgrade their existing CMMs with new software or controllers, or to move or outsource their inspection, system compatibility becomes a big problem. The Metrology Automation Association estimates that compatibility issues cost users more than $1 billion annually.

To understand this, consider just one of the costs of outsourcing dimensional measurement: Even if a client has already written its own CMM part inspection program, an inspection service usually must rewrite the programs to run on its own software and equipment, at a cost of about $85 per hour, says Larry McInerny, programmer and inspector for QC Inspection Services in Burnsville, Minnesota. Depending upon the number of measurements, one part can take from one to 40 hours to program, says McInerny. Even when inspection stays in-house, changing software or CMM hardware can mean thousands of hours of reprogramming and debugging for hundreds of parts.

Although harder to quantify, compatibility issues hurt CMM manufacturers as well. As CMM software functionality increases --such as enhanced user interfaces and the ability to directly read CAD files and compare CAD data to measurement data --so does the user's reluctance to switch software. In many cases, a fortune has been spent on programming and training. In other cases, a specific software package is required companywide (e.g., Volkswagen just signed a contract with Metrologic Group that makes the French software company's Metrolog II the standard metrology software for the German automaker). If a CMM manufacturer doesn't support the software, it may lose a sale --not a good thing, particularly at a time when the MAA reports that CMM manufacturers have sustained at least two straight quarters of losses, and CMM company mergers and acquisitions are almost a quarterly event.

So what's the big deal? Why is a common CMM interface so difficult to accomplish?From the manufacturer's point of view, a common interface solution based on an open standard leans toward a lowest-common-denominator interface that diminishes a manufacturer's competitiveness. Back in the 1960s, at the dawn of CMM computer automation, each CMM manufacturer developed its own CMM control and measurement hardware and software. As the products evolved, manufacturers built features into the hardware and software that gave a CMM its particular edge over the competition. These edges are important in a relatively small market.

Brown & Sharpe estimates that there are only about 100,000 CMMs of all brands in the field worldwide. By making your product accessible via an open standard, "you can work yourself out of business," says Dave Genest, marketing director for Brown and Sharpe. "If the customer says it would like to have an open architecture choice, you have to change your product to be open architecture. But, if everyone has an open architecture, we all start to look the same and we lose a marketing advantage."

To protect that advantage, manufacturers take steps to hide key features from any software but their own, say many software producers. "Today most CMM controllers are almost the same, but each may have it's own advantages," says Bertrand Gilli, president of Metrologic Group, which produces both CMM software and controllers. "If CMM makers want to have an advantage, they won't make available the commands that take advantage of these enhancements."

Additionally, manufacturers like Brown & Sharpe don't want to lose business to aftermarket retrofitters. The 100,000 CMMs in the field are made largely of granite and steel and will last until the sun goes out. Rather than buy new CMMs, existing users choose to upgrade the electronics and software. Manufacturers want to make sure that existing owners come back to them and not a competitor for upgrades. Open standards make it easier for existing customers to go elsewhere.

Finally, jumping through hoops just to meet the needs of a few customers doesn't make good business sense, says Bill Fetter, CMM marketing manager for Sheffield Automation LLC. "The real issue is that this industry isn't big enough," explains Fetter. "For every CMM that the CMM industry sells,

the machine tool industry sells 20. The CMM industry doesn't have the volume. You have customers trying to drive the behavior of the manufacturers. But the manufacturers realize that they're only going to make two of these things. This is a real frustration."

Open application standards: DMIS

The first concerted effort at standardizing data-sharing among CMM software came about in the 1980s. Aerospace and automotive industry leaders wanted a common language that would give them the ability to read data directly from a CAD package and create or perform a measurement routine on one brand of measurement software and have it work on another brand. In fact, in 1983, at a meeting of 100 quality professionals at the Consortium for Advanced Manufacturing International, the need for a common interface among inspection equipment topped the list of key issues facing quality professionals, according to Bailey Squire, CAM-I's director of standards. Several years later, the Dimensional Measuring Interface Standard emerged from CAM-I.

Because CMM manufacturers were anxious to align themselves with Ford Motor Co. and the other large manufacturers behind DMIS, they did their best to implement it, says Curtis Brown, chairman of the DMIS standards committee. The results weren't outstanding.

"One application could spit something out in DMIS format, and another could suck it in," says Brown. "[But], DMIS obviously didn't contain all the capabilities that people needed. CMM companies adhered as best they could."

The problem was that, although set up to do so, the DMIS committee couldn't quickly accommodate changes to the standard. CMM-specific commands, the commands that gave a CMM its edge, took too long to get reviewed and entered into the DMIS specification. This and the lack of enforcement to the standard led CMM vendors to release their own flavors of DMIS. Each DMIS version supported that particular manufacturer's specific commands.

DMIS quickly devolved into a nonstandard. What was left was better than before but fell short of what was needed or intended.

To address the issue of a weakened standard, the recent DMIS 4.0 release provides a general description of what it means to conform to the standard and provides several levels of conformance, says Squire.

Despite its shortcomings, DMIS is still the only game in town for CMM application-to-application compatibility.

Common machine interface

For in-house dimensional measurement, compatibility between different software applications probably isn't as serious an issue as the ability of a software title to communicate with different brands or models of CMMs. As both OEMs and third-party CMM software producers add functionality to their software, it becomes more important to the end user. In a sense, CMM hardware has almost become a commodity, a peripheral device, a very expensive data gatherer. Except in special cases, the user's choice is less, "What can the CMM do?" and more, "What can the software do?" It's for this reason that we see CMM manufacturers partnering with third-party software producers. The writing is on the wall: Customers have begun to gravitate toward the application rather than the equipment and at times, as with Volkswagen, specify the software and not the machine.

Should a company want to upgrade its CMM or purchase a new CMM, the inability of its existing software to communicate with a different CMM or CMM retrofit puts the company in a bind. The options are to reprogram inspection routines using the other CMM's software (expensive and time-consuming), retrofit the other CMM with electronics that the current software supports (very expensive and not a wise move say some CMM manufacturers), or export test routines from the current software, import them into the other software and hope that the translation is accurate. DMIS was supposed to allow this type of export/import functionality but because of the flavored-DMIS problem, the translation is often buggy.

To address the machine compatibility issue, most OEM and third-party software producers include drivers for the most popular brands of CMMs. Some manufacturers provide these drivers to software producers on demand. Others do not, or only provide the drivers to particular software companies. When they don't have access to controller-driver specifications, CMM software producers are left with two choices:

Partnerships. The software manufacturer signs a partnership agreement with the CMM manufacturer. The manufacturer agrees to share all information necessary to allow the software company to write the communication portion of its software so that it can control that company's devices. The advantage is that hardware/software communication issues are addressed during development and with both parties participating in problem solving. This likely means a more stable and integrated interface. It also means that both parties have better access to each other's clients.

Reverse engineering. When a software company doesn't have access to driver information it can still reverse engineer the CMM's communication protocol. The advantage is that this can be done with any controller without the consent of the manufacturer. The downside is obvious: If a problem occurs, to whom does the user turn, the CMM manufacturer or the software producer?

The ideal solution to communicating with all CMMs would be some sort of common equipment interface --the Holy Grail of dimensional measurement equipment. A common interface would be the standardized method for communicating to any CMM controller. All software would speak the same language when talking to the interface. Rather than the burden being on the software to understand how to communicate to all controllers, each manufacturer's controller would understand the common interface language. All controllers would have to support this standard.

I++ DME and DmisEquip

In 2001, a European consortium of automakers (Volvo, DaimlerChrysler, Volkswagen, Audi and BMW) formed I++ and fast-tracked a common machine interface called I++ DME.

Utilizing a small team relatively unhampered by bureaucracy, I++ outlined, spearheaded and delivered a standard in less than two years.

From the user's standpoint, I++ DME provides a common machine interface that, when used with I++ DME-compliant CMMs, ensures that all CMMs behave the same way with any I++ DME-compliant software.

From the manufacturers' viewpoint, an advantage with I++ DME is that it allows the manufacturer to hide sensitive information while still giving users full access to special features.

As with DMIS, the sheer force of the European automakers has ensured that CMM manufacturers begin implementing the I++ standard, again, grudgingly, though maybe a little less so.

Manufacturers acknowledge that the force behind I++ (read, customers) is much larger than that of DMIS.

"I think I++ is a necessary evil," says Genest. "The European automakers have decided that they want to buy CMMs like you buy printers. You buy a printer, a computer, some software and you put it together. The advantage is you aren't limited by any manufacturer's weakness.

"The disadvantage is the whole thing may not work. Who takes responsibility for making the whole system work? Currently, the CMM manufacturer takes responsibility. [Open standards] may put the pressure back on the customer."

In order to meet the needs of users, software companies and measurement equipment manufacturers, the I++ DME interface will have the following characteristics, according to release 1.3 of the standard:

State-of-the-art technology that remains useable in older systems

Scalability

Extendibility. It will be possible to add new types of machines.

The complexity and vendor-specific know-how of the real machine can be hidden behind the interface.

Self-explaining, consistent and complete. Although complex, the interface will be in a notation that is easily understood.

Also responding to the need for a common machine interface, the DMIS committee developed a common machine specification, DmisEquip, as part of the DMIS Part II specification. The goal of DmisEquip is much the same as that of I++ DME.

Early on, DmisEquip addressed key issues omitted by an earlier version of I++ DME, such as support for scanning, nontouch commands, rotary tables and calibration. The I++ committee quickly addressed those issues in release 1.3.

I++, driven largely by European automakers, seems to be taking a much stronger hold than DmisEquip. Most software, hardware and industry people interviewed for this story indicated that the I++ DME standard will become the machine interface standard of choice over DmisEquip.

Both DMIS Part II and I++ DME are working with NIST to develop conformance standards for DMIS and a test suite for I++ DME.

Renishaw: stirring the waters

Many software companies indicate that the industry should be keeping a sharp eye on Renishaw, the Illinois-based probe manufacturer. Holding a majority of the probe market, the company's probes are ubiquitous among CMM producers.

Recently, Renishaw has been ardently promoting its Universal CMM Controller, UCC1. Many in the industry believe that the UCC1 may eventually become the controller that customers demand in systems that call for scanning probes.

In an ironic twist, in the same way that CMM manufacturers claim that the best way to take maximum advantage of their CMM is to use it with their software, Renishaw is making the same claim about the UCC1 and its scanning probes --which are the scanning probes that many CMM manufacturers use (Renishaw also has the majority of the scanning probe market). "To take full advantage of the powerful capabilities of Renishaw's new generation of scanning probes, such as the compact SP25M and ultra-high accuracy SP80, CMM users need their machines to be equipped with the UCC1 controller," says Renishaw's Ben Taylor.

Because the UCC1 interface is in the public domain, it opens up the UCC1 and scanning probe capabilities to all software producers. Renishaw's controller could do to the CMM industry what Fanuc did for machine tools or what Intel did for the computer industry, says Ken Sheehan of Entelegence Software Solutions, producers of Virtual DMIS software.

"You have to pay attention to the significance of Renishaw," says Sheehan. "You will see CMM manufacturers making just the mechanics and then plugging in Renishaw. They are the Intel of this industry."

The customer

So what does all this mean for the customer? The third-party software producers will tell you it's great for the customer because, as Gilli says, "Customers can order the machines they need rather than the ones that have the software they need." The CMM manufacturers don't paint quite as rosy a picture. Although Genest and others agree that it does give customers versatility in matching both hardware and software to their particular needs, they also believe customers should be made aware of the pitfalls.

If Brown & Sharpe puts its own PC-DMIS software on an LK CMM, it's the company's responsibility to make sure the software works with the hardware, says Genest. "We're in the driver's seat in terms of making it work. But, if the LK machine [breaks] we wouldn't fix it. The customer would go back to LK."

Also, unlike using PC-DMIS on its own CMMs, Brown & Sharpe doesn't take responsibility for overall system accuracy when mixing and matching software and hardware.

Sheffield Automation has taken a hard line on this issue and doesn't help third-party hardware or software producers connect to its CMMs. It's all about maintaining the quality of its product, says Fetter. He points out that unlike other CMM manufacturers, Sheffield has been making motion controllers for many types of equipment besides CMMs for decades and understands their dynamics better than others. Therefore, Fetter believes that Sheffield's controller/software combination can't be beat utilizing a mix-and-match combination.

"Is my CMM as good with someone else's controller as it is with mine?" asks Fetter. "No. The bottom line is the customer wants to accomplish something. They have a task to accomplish in a certain amount of time. We try to supply a solution for doing that. We believe that we have the most control over the quality of the user's solutions when we offer the whole package."

I want my plug-and-play

The CMM manufacturers see it coming. The software companies see it coming. For better or worse, plug-and-play CMMs are on their way. Our culture views life through a 17-inch flat screen, Microsoft-powered 2 Ghz Intel-driven computer, and we expect our $125 printer and quarter-million dollar CMM to connect easily to our IBM ThinkPad.

As the CMM manufacturers and software producers work hand in hand to give the customers what they want, we have to hope that the drive for plug-and-play won't result in highly compatible but mediocre products.

About the author

Dirk Dusharme is Quality Digest's technology editor. Letters to the editor regarding this article can be sent to letters@qualitydigest.com.