Part 1 defines an input file format for the off-line transfer of a complete inspection sequence to a CMM or other inspection equipment for later execution, and defines an output file format for inspection results for processing following execution completion. Part 2, on the other hand, defines a protocol for the direct, on-line control of inspection equipment and the interactive retrieval of inspection results by a software program for immediate processing during inspection operations. As a standardized object oriented API, DMIS Part 2 enables plug-and-play for CMM applications, and provides a modular environment that supports the integration of separate software applications into a customized solution for user needs.

Overview
DMIS Part 2 is an open architecture interconnection technology for inspection software applications. Part 2 defines the format of communications between CMMs, the DMIS language, and inspection applications. DMIS Part 2 is fundamentally DMIS, as software objects; but it overcomes the limitations inherent in the monolithic model of DMIS Part 1 by using object-oriented IDL interfaces. Part 2 makes it possible to extend equipment capabilities and to provide access to inspection data for software applications in a flexible, open manner.

The IDL interface permits all dimensional inspection equipment data and status to be queried interactively, allowing features, tolerances, measurement points, status, and 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 real-time process control applications.

Part 2 allows the manipulation of inspection objects to be interleaved with the direct execution of DMIS text statements. As objects are created and manipulated using the IDL object interface, the corresponding DMIS statements may be automatically generated and inserted into the program at the current point of execution. Conversely, DMIS statement execution causes appropriate objects to be allocated. In either case, both the objects and the statements are immediately available to all Part 2 compliant applications for query and manipulation.

DMIS Part 2 compliant applications can find the desired dimensional inspection equipment using a naming service. Once the application connects to a Part 2 server as a client, it can obtain complete information on the status of the machine, a list of all available program symbols (features with data points, tolerances with result data, sensors, etc), 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, DMIS Part 2 issues asynchronous events to notify all registered event consumers (Part 2 clients) using asynchronous event notification. This allows each client application to immediately update displayed or stored information, and to optionally respond with further commands.

The inspection equipment object interface has methods for initiating machine motion, probe articulation or control, and sample operations; and for retrieving sample data, current position, machine status, and error conditions. For the most part, these reflect a fairly high level of information, containing the normalized content of the applicable DMIS Part 1 command. However, the equipment control module handles the details of machine control, such as servo control, probe interfacing and rotary table support, software 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).

Result calculation and tolerancing may optionally be separated from the language core. The object interface defines the data structures and mathematical operations that may be supported by a mathematics subsystem.

Understanding Objects
Object-oriented software development is primarily a technique for identifying the fundamental components of a system (called objects), for combining the data for an object with the operations on that data (called encapsulation), for preventing direct access to the data structures which are associated with that object (called data hiding), and for grouping together objects with similar behavior or function (called polymorphism).

In a combustion engine, some objects might be pistons, valves, camshafts, and spark plugs. In DMIS Part 2, the objects include carriages, sensors, features, tolerances, and coordinate systems.

A carriage, for instance, encapsulates current acceleration and velocity data; a carriage also has a current probe position. Operations (called methods) on a carriage object would get or set the acceleration, move the carriage sensor to a specific location, home the carriage, or request the current position of the sensor. Data hiding makes it unimportant whether the data is stored within the carriage object or is obtained from the inspection hardware when requested, as long as the data can be accurately returned. Nor is it important how an object performs an operation, as long as the results are correct.

Features, for instance, can be further refined into arcs, cones, cylinders, and other geometric types. These share common operations with similar, yet distinct, behaviors: such as applying and outputting tolerances. This is known as polymorphism.

In a nutshell, since software objects often map to real world entities, they make a software system easier for software developers to understand and to use. Objects also make the software more flexible, more adaptable to change, and easier to customize.

An Object Specification
Part 1 defines a number of inspection program entities which map to real or theoretical items within an inspection device (DME - Dimensional Measurement Equipment, typically a CMM - Coordinate Measurement Machine) or on a manufactured part (workpiece). For instance, a CMM has one or more carriages, one or more sensors, and may have a rotary table. A workpiece typically has various holes, flat surfaces, slots, and other cut-outs and protrusions. In order to suitably tolerance such features on a workpiece, at least one datum reference frame is typically needed. Part 1 defines carriages (using the CRGDEF statement), sensors (SNSDEF), and rotary tables (ROTDEF). It also defines features (FEAT), tolerances (TOL), part coordinate systems (DATSET, LOCATE, ROTATE, TRANS) and, as a part of specific tolerances, it defines datum reference frames at specific material conditions.

Part 2 takes these syntactic textual entities, and maps them to object definitions which form an Application Programming Interface (API) for connecting separate software programs. There is, in most cases, a direct, one-to-one mapping between the program entities of Part 1 and the object interfaces of Part 2. For instance, there is a Carriage object in Part 2 which corresponds to the carriage entity defined by the Part 1 CRGDEF statement. Similarly, there is a Feature object in Part 2 which corresponds to the feature entity defined by the Part 1 FEAT statement.

Part 1 also defines various commands which map to operations on the DME or workpiece. For instance, commands are provided for machine motion (GOTO, GOTARG), and feature measurement (MEAS, PTMEAS, RMEAS).

Part 1 commands map, not to objects, but rather to methods on the appropriate Part 2 object. For instance, a GOTO command applies only to the carriage for which it is executed; so the Part 2 Carriage object has a goto() method. Similarly, a Part 2 RotaryTable object has a rotate() method corresponding to the Part 1 ROTAB command.

Most Part 1 statements also require parameters to fully define the entity or operation. These parameters may be obtained from the Part 2 objects using accessor methods.

CRGDEF Defines a sensor-carrying carriage. Example: CR(1)=CRGDEF/-100,-100,-50,300,300,400,1,0,0,0,1,0,0,0,1,0,0,-1 HOME Sets the home position for the carriage. Example: HOME/100,0,125 GOHOME Moves a carriage to its home position. Example: GOHOME GOTO Moves a carriage to the specified location. Example: GOTO/25,232.5,-179.2 PTMEAS Takes a single measurement point (in touch probing mode) or initiates a scan (in scanning mode). Example: PTMEAS/CART,33.675,122.32745,-12.23,0.000,-0.7071,-0.7071

struct CarriageDef { Triple_t zero_ref; Triple_t extent; Triple_t ijk_x; Triple_t ijk_y; Triple_t ijk_z; Triple_t axis_dir; }; interface ObjectFactory : Factory { Carriage new_Carriage (in Client client_id, in string sym_name, in CarriageDef carg_def); }; interface Carriage : Symbol { void get_carriage_data (out CarriageDef carg_def); void select_sensor (in Sensor sens); void set_meas_accel (in eCARG_ACCEL units, in double opt_accel); void set_home (in Triple_t home); void go_home (); void go_to (in Triple_t pos); void meas_prog_point (in Triple_t pos, in Triple_t opt_ijk); };

FEAT/CIRCLE Defines a circle feature. Example: F(cir_01)=FEAT/CIRCLE,INNER,CART,100,125,20,0,0,1,32.5 BOUND Applies a bounding plane to a feature. Example: BOUND/F(cyl_01),F(BND_PLN01),F(BND_PLN02) GEOALG Applies an alternate geometric point fitting algorithm. Example: GEOALG/CIRCLE,MININS UNITS Sets the current measurement units. Example: UNITS/CM,DEC,TEMPC EVAL Evaluates a tolerance against a feature. Example: EVAL/FA(CIR_01),T(CRLTY_01)

interface ObjectFactory : Factory { FeatCircle new_FeatCircle (in Client client_id, in string sym_name, in eFEAT_INNER_OUTER inner_outer, in Triple_t pos, in Triple_t dir, in double diam); }; interface System : Client { eANG_UNITS get_ang_units (); eLIN_UNITS get_lin_units (); eTEMP_UNITS get_temp_units (); void set_units (in Client client_id, in eLIN_UNITS lin_units, in eANG_UNITS ang_units, in eTEMP_UNITS temp_units); void set_bound_feat (in Client client_id, in FeatNom target, in FeatSeq feat_list); void evaluate_tol (in Client client_id, in FeatAct feat, in TolNom tol); FeatAct construct_project (in Client client_id, in FeatNom target, in FeatAct feat_1, in Feature opt_feat_2); };   interface Feature : GeomElem { eFEAT_TYPE get_feat_type (); }; interface FeatNom : Feature { FeatSeq get_bound (); GeoAlg get_geoalg (); }; interface FeatAct : Feature { PointSeq get_comp_points (); PointSeq get_nom_points (); RawPointSeq get_raw_points (); }; interface FeatCircle : FeatNom { eFEAT_INNER_OUTER get_inner_outer (); Triple_t get_pos (); Triple_t get_dir (); double get_diam (); }; interface FeatACircle : FeatAct { eFEAT_INNER_OUTER get_inner_outer (); Triple_t get_pos (); Triple_t get_dir (); double get_diam (); };

Document Overview
The DMIS Part 2 standard is a soft-cover, soft-bound document consisting of 481 pages. The document comprises the following sections:

1. Scope
2. Conformance
3. Normative References
4. Terms and Definitions
5. System Reference
6. Interface Reference
Appendices
A. CORBA IDL
B. COM IDL
C. Part 1 Characterization

System Reference
Section 5 contains the System Reference. This provides general information about data formats and parameters, system configuration, sensor calibration, and probe compensation within the Part 2 environment. It also defines requirements for initialization, shutdown, and configuration of each of the supported modules: DMIS Implementation, DMIS Equipment module, DMIS Mathematics module, and DMIS Applications.

It contains the following:

5. System Reference
  5.1 Data Representation
  5.2 Parameters
  5.3 Configuration
  5.4 DMIS Implementation
    5.4.1 Initialization, Shutdown, and Initial References
    5.4.2 Initial and Reset States
    5.4.3 DMIS Statement Generation
    5.4.4 Multi-carriage Operation
    5.4.5 Events and Exceptions
    5.4.6 Object Lifetime
    5.4.7 Locks
  5.5 DMIS Equipment Modules
    5.5.1 Initialization, Shutdown, and Initial References
    5.5.2 Initial and Reset States
    5.5.3 Object Lifetime
    5.5.4 Multi-carriage Operation
    5.5.5 Exceptions
  5.6 DMIS Mathematics Modules
    5.6.1 Initialization, Shutdown, and Initial References
    5.6.2 Initial and Reset States
    5.6.3 Object Lifetime
    5.6.4 Multi-carriage Operation
    5.6.5 Exceptions
  5.7 DMIS Applications
    5.4.1 Initialization and Shutdown
    5.7.2 Events Handling
    5.7.3 Locks
  5.8 Sensor Calibration
  5.9 Probe Compensation

Interface Reference
Section 6, Interface Reference, contains detailed syntactic and semantic descriptions for each of the structures, enumerations, and interfaces defined in DMIS Part 2.

It contains the following:

6. Interface Reference
6.1. Global types
6.1.1. Type Definitions
6.1.2. Structures
6.2. module Dmis
6.2.1. Type Definitions
6.2.2. Enumerations
6.2.3. Structures and Unions
6.2.4. Interfaces
6.2.5. Exceptions
6.2.6. Output and Notification Events
6.2.6.1. Fundamental Event Interfaces
6.2.6.2. Error Event Interfaces
6.2.6.3. Program Event Interfaces
6.2.6.4. System Event Interfaces
6.2.6.5. Output Event Interfaces
6.3. module DmisEquip
6.3.1. Type Definitions
6.3.2. Enumerations
6.3.3. Structures and Unions
6.3.4. Interfaces
6.4. module DmisMath
6.4.1. Type Definitions
6.4.2. Enumerations
6.4.3. Structures and Unions
6.4.4. Interfaces

Annexes
The appendices contain additional information relevant to the different components of DMIS Part 2. They contain the following:

A. Annex A – CORBA IDL
A.1. Configuration
A.2. Initialization
A.2.1. DMIS Implementation
A.2.2. DMIS Equipment Modules
A.2.3. DMIS Mathematics Modules
A.2.4. DMIS Applications
A.3. Shutdown
A.3.1. DMIS Implementation
A.3.2. DMIS Equipment Modules
A.3.3. DMIS Mathematics Modules
A.3.4. DMIS Applications
A.4. Initial References
A.4.1. DMIS Implementation
A.4.2. DMIS Equipment Modules
A.4.3. DMIS Mathematics Modules
A.5. IDL Definition
B. Annex B – COM IDL
C. Annex C – Part 1 Characterization Level

Sample Pages
Several sample pages from Section 5 and Section 6 of the DMIS Part 2 ANSI standards document may be viewed using the free Adobe Acrobat Reader. (Used by permission.)

Related Information
See also the DMIS Part 1 standard.

Browse DMIS FAQs.
Order the DMIS standards documents online.