The Dimensional Measurement Interface Standard (DMIS) is designed to change that situation. The two-part standard is meant to provide interoperability among different applications and systems: Part 1 focused on off-line programming and results data interchange, while Part 2 advances this into the on-line, real-time realm.
The inspection dilemma
It can be a substantial task to make different inspection applications exchange even simple information, let alone share it in a dynamic, real-time manner. Most vendors do not have the resources, or the software architecture, to support such interapplication communication--certainly not across the many permutations of available metrology software. Furthermore, each of the dozens of controller types on the factory floor use a unique protocol for passing commands, results, status and errors.
This means that, far too often, the burden of management and integration of metrology applications and diverse equipment falls heavily upon user-support staff, substantially raising the internal cost of CMM ownership and adding complexity to product inspection development and roll-out.
DMIS is perhaps the only existing metrology programming standard that focuses on the interchange of static inspection commands and results data. Looking back to its roots, DMIS satisfies its original objective: it provides a human-readable, post-processing file format for inspection sequences and results. Its use has grown and today it is also commonly applied as a native programming language for CMMs. The DMIS specification now defines a rich set of commands to enable virtually any real-world inspection task.
However, while these advances improve the outlook for off-line programming, and even inspection execution, they do not address the problems of inspection application integration and controller interfacing. Solving these problems is the primary purpose of a pending companion standard to the original DMIS specification: the new DMIS Part 2 specification. Over the past several years, various members of the DMIS National Standards Committee (DNSC), which is sponsored by the Consortium for Advanced Manufacturing International (CAM-I, Bedford, TX), have developed the Part 2 specification. Based on DMIS Part 1, the second specification takes the commands and results outlined in Part 1, and defines a way for applications to share and communicate this information dynamically in real time. The result is a powerful mechanism for seamless integration of inspection applications within the factory.
The DMIS Part 2 specification uses leading technology designed to build on the DMIS Part 1 standard. Numerous end users, CMM suppliers and other vendors, government agencies and universities contributed to its development, review and refinement, including: Daimler-Chrysler, Ford, John Deere, Honeywell, Brown & Sharpe, Carl Zeiss, Giddings & Lewis, Object Workshops, Perceptron, SILMA, NIST and McMaster University.
For developers, DMIS Part 2 opens up the CMM and simplifies inspection application development. Curtis Brown, current chairman of the DNSC and staff engineer for Honeywell Federal Manufacturing & Technologies (FM&T's) Science-Based Manufacturing Div., is proving-in Part 2 functionality with test applications. "The Part 2 specification provides a common interface that enables rapid integration of metrology applications, enabling developers to take advantage of advances being made in the inspection software industry," Brown says.
Leading edge university researchers are also aware of the opportunities that open-architecture metrology brings them. Dr. Allan Spence, an associate professor in the Department of Mechanical Engineering at McMaster University (Hamilton, Ontario, Canada) says, "The current lack of metrology interoperability distracts us from concentrating on the scientific aspects of our research. DMIS Part 2 will address this, and generally strengthen industry commitment to DMIS. As we move toward direct, on-line CAD/CAM/CMM integration, the proposed DMIS Part 2 standard will accelerate transfer of our technology to industrial partners."
For software developers, the key to writing powerful applications that work well together is a broad programming interface to a common set of underlying services. Microsoft Windows is a good example of how applications written by many different companies can work together on a single computer--because they all are written to a common programming interface, the WIN32 API.
DMIS Part 2 enables third-party inspection applications to be connected to a metrology device such as a CMM and interactively develop inspection programs, dynamically track inspection results and data, capture design information and effectively control inspection equipment. The DMIS Part 2 specification supplies a rich programming interface that makes it easy to control and access the capabilities provided in DMIS Part 1. It is, in effect, the WIN32 API for metrology.
Whether used for on-line programming, statistical process control, production inspection and rework, on-tool inspection, or reverse engineering, DMIS Part 2 enables true plug-and-play for metrology. The open architecture will enable inspection-users to buy off-the-shelf software to customize inspection equipment with tools like computer-aided-design, or CAD-based, on-line programming front-ends, 3-D graphical analysis tools, statistical monitoring and control packages, interactive program editors and CMM simulators. And, because it is based on Internet-ready protocols, Part 2 applications will work across high-speed local area networks (LANs) and wide area networks (intranets).
From serial interfaces passing cryptic encoded text commands all the way to ISA- or PCI-based boards using dual-ported memory, there is tremendous diversity in the design and communications protocol of the motion controllers used on CMMs and other inspection devices on the shop floor. It is simply not possible, or even desirable, to impose constraints on the design of these controllers or their interface.
However, DMIS requires a common set of operations to be performed by a controller. Measurement, clearance moves, wrist rotations, rotary table motion and tool changing are all defined within the DMIS Part 1 specification. The corresponding operations are provided in DMIS Part 2. Just as Windows defines various device driver models that enable sound and video cards, printers and other devices to be supported, so DMIS Part 2 defines an equipment control driver model that enables various inspection devices to be supported.
Cones and cylinders
DMIS is typically used for inspection of prismatic features such as cylinders, cones and planes because these are well parameterized and easily described mathematically. In addition, it defines support for two-dimensional curves and three-dimensional surfaces. However, other useful mathematically concise features--such as paraboloids, hyperboloids and toothed gears that can be useful elements of an inspection toolbox--are not directly supported in DMIS.
DMIS Part 2 makes use of the Part 1 user features and tolerances to provide extensible math capabilities. Mathematics modules can be plugged-in, similar to device drivers, to simplify adding support for these and other custom features.
Because the DMIS Part 2 interfaces are network accessible, inspection software developers can now focus on the bigger picture: reducing manufacturing process errors by using inspection results in real time. This can translate into millions of dollars of cost savings for inspection users by reducing scrap and rework.
The basis for DMIS Part 2 standardization is the DMIS Part 1 text-based specification, reduced to a complete Interface Definition Language (IDL) specification. The IDL contains three major sections:
The DMIS module interfaces permit all dimensional inspection equipment data and status to be queried interactively, allowing features, tolerances, measurement points, status and the program state to be accessed while a program is being executed, as well as providing control over program execution. This, along with remote network access capabilities, provides support for advanced real-time application integration.
Part 2-compliant applications can find the desired dimensional inspection equipment using a naming service. After the application connects to a DMIS implementation as a client, it can obtain complete information on the status of the machine, a list of all available program symbols like data points, tolerances with result data and sensors, or a reference to an individual symbol object. Each of these objects has operations, called methods, which may be invoked to cause the inspection equipment to perform some task or operation. In response, the implementation issues asynchronous events to notify all registered Part 2 applications. This allows each application to immediately update displayed or stored information, and to optionally respond with further commands.
DMIS Part 2 allows the manipulation of inspection objects to be interleaved with the direct execution of DMIS statements. As objects are created and manipulated using the interface methods, the corresponding DMIS statements are inserted into the program at the current point of execution. Conversely, DMIS statement execution causes appropriate objects to be allocated. In either case, the objects and the statements are immediately available to all Part 2-compliant applications for query and manipulation.
The DMIS Part 2 driver interface does not attempt to minutely dictate the details of inspection machine control, but instead broadly identifies the available and required data at the language and system levels. The machine control subsystem handles servo control, probe interfacing and rotary table support, software-based error compensation, closed-loop data sampling for touch probing or single-point video detection, and open-loop data sampling for high-speed analog or laser scanning, or multi-point video edge detection. The carriage, sensor and rotary table objects contain methods to initiate machine motion, probe articulation and data sampling. They are also used to retrieve sampled data, current position, machine status and error conditions.
Result calculation and tolerancing are separated from the implementation core. The object interface defines the data structures and mathematical operations that must be supported by the mathematics subsystem. This allows the mathematics subsystem to be upgraded with a higher accuracy package as the ANSI-Y14 standard evolves, or upgraded with a standards-based package for validation. It provides a standard and portable way to directly extend DMIS with user features, such as gears and paraboloids, and to integrate new advances in measurement techniques.
Customers drive DMIS
Users of inspection equipment are economically driven to increase quality, reduce costs, and improve productivity. The increased compatibility, as well as the broader availability of inspection applications will enable them to realize these requirements. Vendors are driven by customer needs to increase features and minimize costs and to develop applications that can exchange data with one another.
The DMIS standard has enabled a fundamental level of static communication between different components of an inspection system; however, this standard does not address the requirements of real-time, interactive communication between different inspection tools, including data transfer and event notification. Vendors are currently forced to develop proprietary solutions to these needs, increasing their costs, limiting the number of supported applications and delaying time-to-market. This limits the options from which users can choose, and often prevents them from obtaining a solution that realizes their needs.
The standardization of an open architecture-programming interface between a DMIS-based implementation and an inspection application will allow for high-speed data transfers, and for plug-and-play integration of external applications.
The potential benefits to the inspection world are enormous. It would create a broader choice of plug-and-play solutions to inspection customers, support a framework for cooperation among different vendors, eliminate redundant software development overhead, and create an economic incentive that could encourage the development of emerging technologies by small companies and researchers.