• How can I get a copy of the current standards documents?
  
• How can I ask for changes to the DMIS standard?
  
• What is the status of the DMIS standardization effort?
  
• Is there any training for using the DMIS standard?
  
• How is DMIS Part 2 different from DMIS Part 1?
  
• Can you give me a brief overview of DMIS Part 2?
  
• Is DMIS Part-2 a standard or an application programming interface (API) definition?
  
• How are the DMIS Part 2 objects defined from the Part 1 specification?
  
• What is the role of the DMIS Part 2 Kernel? Does it merely broker requests between clients and services?
  

How can I get a copy of the DMIS standard?
Both the DMIS Part 1 and the Part 2 standards documents are available as bound printed documents, and on CD-ROM. They may be ordered from the DMIS Standards bookstore.

How can I ask for changes to the DMIS standard?
The DMIS standard is maintained and enhanced by the DMIS Standards Committee (DSC). The DMIS Standards website maintains an SIR (Standards Improvement Request) database, with on-line forms for submitting an SIR to the DSC. The DSC meets several times a year to consider SIRs for corrections and improvements to the standard. The standards meetings are open to anyone, and voting membership in the DSC is encouraged.

What is the status of the DMIS standardization effort?
The DMIS Part 1 version 4.0 document has been formally progressed and accepted as an ANSI national standard and an ISO international standard.

The DMIS Part 2 version 1.0 document has been formally progressed and accepted as an ANSI national standard. It is being submitted to ISO for fast-track approval as an ISO standard.

The DMIS Part 1 version 5.0 document has been formally progressed and accepted as an ANSI national standard. It is being submitted to ISO for fast-track approval as an ISO standard.

How is DMIS Part 2 different from DMIS?
DMIS Part 2 is DMIS - it allows inspection tools to load, generate, and execute DMIS programs. But whereas DMIS Part 1 is a file format, Part 2 is communications protocol.

DMIS Part 1 allows a text file to be structured so that a CMM or other inspection device can understand how to establish a part coordinate system, what features need to measured, and what tolerances need to be applied. It has essentially become an inspection programming language, though originally intended simply as a file transfer specification.

DMIS Part 2 defines a standard way for inspection applications to communicate with CMMs and other inspection devices. This can eliminate the many permutations of post-processors and proprietary communications APIs that are currently used to tie together various inspection tools. It can also significantly reduce the programming effort (C++, Java, etc) to communicate and use DMIS information; and can make it possible for in-house software developers to create their own custom inspection tools to run on a broad range of CMMs.

Can you give me a brief overview of DMIS Part 2?
The primary objective of DMIS Part 2 is to provide standardized interactive communications between a DMIS-based DME implementation and external applications; or to put it in other terms, to provide programming-level access to inspection results and operations in a standard manner, without compromising the integrity of the data or operation of the equipment.

There is currently no standard way to interact with a CMM, other than using DMIS input and output files; and file-based processing essentially restricts a system to batch mode operation. Some DME implementations may provide alternate mechanisms, such as named pipes or shared memory, for interactive processing of output data; and quality applications (such as SPE) may provide other mechanisms, such as DDE or OLE; but the structure and format of each of these mechanisms is highly proprietary and distinctly non-portable. Even with such mechanisms as named pipes for DMIS output, true interactive processing is not possible with multi-carriage machines, since DMIS output must be queued in carriage-specific sections for later output.

DMIS Part 2 provides a mapping of DMIS into objects, so that external applications can in effect become an extension of the DME, initiating and responding to activity within the CMM; but since this occurs using DMIS-based objects, the DME does not incur a greater risk to its integrity than it does by running a DMIS program. (In other words, if DMIS Part 2 were to require shared memory access to DME variables, it would be possible for an external application to overwrite DME data, beyond the control of the DME vendor - a highly undesirable scenario. Instead, DMIS Part 2 specifies function calls, which permit the DME to test parameters, and to reject any invalid requests or operations; and no data within the DME is directly accessed, maintaining the integrity of the DME software).

Is DMIS Part 2 a standard or an application programming interface (API) definition?
Both: DMIS Part 2 is a standard interface definition.

In a nutshell, DMIS Part 2 establishes a standard interface API by which various applications can interact with a CMM or other DME using an object-oriented programming approach. The API is derived directly from DMIS - Part 1 commands have been mapped either to DMIS Part 2 objects (eg. feature and carriage definitions), or to methods on those objects (eg. machine motion).

The key here is that DMIS Part 2 defines a standard INTERFACE; it does not attempt to prescribe an IMPLEMENTATION architecture. For instance, FeatAct::get_comp_points() requires the DME to return the compensated data points for a feature, unless point buffering (PTBUFF) was off. How the implementation performs this is not of interest to DMIS Part 2 - the DME may store all of the compensated data points in memory, it may cause a recalculation of the data points from the raw points at the time of the request, or it could retrieve these points from a disk file. All that matters is that when this data is requested, the DME be able to provide the specified output. Again, DMIS Part 2 is simply defining the interface level, and is not concerned with specific implementation details.

How are the DMIS Part 2 objects defined from the Part 1 specification?
Some of the DMIS statements (and other components of the DMIS specification, such as information from sections 2 and 3) map naturally to objects; others map to operations on these objects. Additional objects, methods, and asynchronous event notification are needed for interactive online communication with a language-based engine in a distributed client environment.

By way of example, features map naturally to an object hierarchy: a base Feature class derives into FeatNom (nominal) and FeatAct (calculated actual or substitute feature) classes, which are further subclassed into FeatArc, FeatAArc, FeatCircle, FeatACircle, etc. A similar hierarchy is derived for Tolerances and Sensors; and many other DMIS types, like Carriages and Rotary Tables map to objects as well. The data members for a FeatCircle are already defined by the specification, which identifies each of them within the Input Format; while the Output Format identifies the data members for a FeatACircle. This is an example of how a DMIS statement maps directly to two object definitions.

But other statements do not map to objects, but rather to operations (or methods). For instance, SNSLCT/ is an operation which, according to the standard, "refers to a specific carriage and consequently must be used inside a carriage section and not on a common section." The standard thus enforces an association between a particular Carriage object and the sensor selection operation: therefore, supplying a Carriage::select_sensor(...) method most naturally falls out of the specification. (An Equipment::select_sensor(Carriage, ...) would be another valid, but less object-orientedly correct, approach).

Since any DMIS system is fundamentally language-centric, some entities must be defined for manipulating a program. Statement, PgmModule (DMISMD), PgmMain (DMISMN), and other objects are not directly derived from the DMIS Part 1 specification, but are rather indirectly implied; these provide a necessary structure to the way that DMIS text statements are queried or inserted within a DMIS program. Other objects and methods support the execution of statements, provide access to program symbols, register for and notify of various equipment and language events, and handle other systemic tasks.

What is the role of the DMIS Part 2 Server? Does it merely broker requests between clients and services?
No. It does indeed manage the client object interface. However, architecturally there are four distinctive components to the system, with three separate object interfaces, and these are key to the flexibility and extensibility of the DMIS Part 2 architecture.

Beyond its role of brokering object requests for clients, the DMIS Part 2 Server contains a DMIS interpreter and execution engine, object-call to DMIS code generation logic, event notification code, and plug-in module loading and routing support. The DMIS Part 2 Server is responsible for accepting client requests, creating objects as necessary, generating DMIS code which parallels object creation and method invocation, loading DMIS programs, executing DMIS statements interactively, issuing parallel execution sequences to and synchronizing between multiple carriages, issuing other DME control statements to the DME subsystem, routing mathematical operations to the appropriate loaded mathematics module, and notifying clients of DMIS execution and engine state changes.

The client interface makes it possible for a DMIS Part 2 client application to query and follow what is happening within the DMIS environment - what features, tolerances, and other symbols have been defined, when features have been measured, when tolerances have been applied, when the part coordinate system changes, what actual data points were sampled for a feature, etc. The mathematics plug-in interface supports user-defined features and tolerances, and provides a standard way to load and execute custom measurement (DMEALG) and calculation (GEOALG) algorithms. The DME control plug-in interface focuses entirely on those DMIS commands which deal with CMM motion, including measurement, scanning, rotary tables, and calibration.

The object interfaces are actually the components which are standardized - that is, the definition of the objects and their methods for communication between the DMIS Part 2 Server and: the client applications, the DME control subsystem, and the mathematics modules, respectively. This makes it possible, though not always practical, to create wrappers for legacy code to make DMIS Part 2 compliant components.

Related Information
See also the DMIS Part 1 and the DMIS Part 2 standards.