DME Driver Interface Compar

1

A Comparison of

the CMM-driver Specification Release #1.9

with the I++ DME-Interface Release 0.9

T. Kramer and J. Horst

Intelligent Systems Division

National Institute of Standards and Technology (NIST)

March 13, 2002

NISTIR 6863
DME Driver Interface Compar

2

Disclaimer

Commercial equipment and materials are identified in order to specify cer

procedures adequately. In no case does such identification imply recommendation 

endorsement by the National Institute of Standards and Technology, nor does it im

that the materials or equipment identified are necessarily the best available for 

purpose.

Acknowledgements

Partial funding for the writing of this paper was provided to Catholic University by 

National Institute of Standards and Technology under cooperative agreement Num

70NANB7H0016.

Abstract

This is a comparison of (1) the entire contents of CMM-driver Specification Rele

#1.9 and (2) the parts of I++ DME-Interface Release 0.9 that deal with the interfac

a driver for dimensional measuring equipment.

Keywords

CMM, dimensional, DMIS, I++, inspection, metrology, NIST, standard
DME Driver Interface Compar

3

1 Introduction

This comparison focuses on the interface between high-level inspection instruction execution 

low-level inspection instruction execution. This interface is used between an executor of a hi

level language (such as DMIS1) and a CMM2 motion controller, for example. It would also 

used between a CMM user interface and a CMM motion controller. This interface is called 

“DME driver interface” in this report. The receiver of DME (dimensional measuring equipme

driver interface commands will be called the DME driver. The sender of DME driver interf

commands will be called the application.

The items being compared are: (1) the entire contents of CMM-driver Specification Release #

and (2) the parts of I++ DME-Interface Release 0.9 that deal with the DME driver interface

the remainder of this report the version numbers are usually omitted for brevity, but all referen

to these documents mean these specific versions.

Much of I++ DME-Interface deals with matters that are not part of the interface. These 

summarized below but are not analyzed.

The perspective of this report is that one or both documents being compared may beco

standards of a standards body (such as the International Organization for Standardization (IS

or may become de facto standards. In this event, the documents will have to stand on their o

To insure interoperability, the documents will have to be complete and unambiguous. Thus, 

report does not take into account anything the authors or sponsors of the documents have s

about their meaning and intent unless it is also written in the documents.

1.1 Contents of this Report

The remainder of this report includes:

1. general descriptions of the two documents.

2. a presentation of the important issues.

3. a broad comparison of the two documents.

4. a detailed comparison of the two documents.

1.2 Other NIST Documents

Other NIST documents relevant to this comparison (available on request to T. Kramer) include

1. Analysis of Dimensional Metrology Standards; NISTIR 6847.

2. a proposed revision (from December 2000) of an earlier version of the CMM-driver

Specification.

3. a comparison (from December 2000) of the low-level command set used in the NIST.

DMIS interpreter with the commands from the CMM-driver Specification

4. an eight-page set of detailed comments (from November 2000) on the CMM-driver

Specification.

1. DMIS = Dimensional Measuring Interface Standard

2. CMM = Coordinate Measuring Machine
DME Driver Interface Compar

4

2 General Descriptions

2.1 General Description of CMM-driver Specification

The CMM-driver Specification Release #1.9 is a 44-page document that was developed 

representatives (Lutz Karras [Carl Zeiss], Michel Penlae [Xygent], David Smith [LK], and 

Wilcox [Brown & Sharpe]) of four companies working the area of metrology hardware 

software.

The entire text of the CMM-driver Specification deals with a DME driver interface.

The CMM-driver Specification specifies a method of communicating and a set of commands.

Implementations of the CMM-driver Specification have been built and tested.

2.2 General Description of I++ DME-Interface

The I++ DME-Interface Release 0.9 is a 62-page document that was developed by representati

(Hans-Martin Biedenbach [Audi], Josef Brunner [BMW], Kai Gläsner [DaimlerChrysler], Gün

Moritz [Messtechnik Wetzlar], Jörg Pfeifle [DaimlerChrysler], and Josef Resch [Zeiss IMT]

three automobile companies and two companies working the area of metrology hardware 

software.

The I++ DME-Interface document specifies an object-oriented system. The focus of 

document is on an object called the DME-Interface. This is an object, not an interface; to av

confusion, we will call this object the DME-I. Page 9 of the document shows a system layout w

the DME-I at the center. The layout includes a line joining the DME-I to an application. This 

is the DME driver interface in which we are interested. The DME-I is responsible for 

subsystems of the DME, so all commands and responses flow through the DME-I. Thus, alm

all of the contents of the document deal with the interface in which we are interested.

The DME-I is modeled as an instance of an object class in a class hierarchy including the clas

Server, DME, Cartesian CMM, and Cartesian CMM with Rotary Table. The DME-I 

associated objects, the most important of which are tool changers, tools, and axes.

For the most part, the details of the how the DME-I is modeled can be ignored without creat

any misunderstanding about the commands and responses the DME-I can handle. This report w

say nothing further about the object modeling of the DME-I unless it is essential.

The I++ DME-Interface document appears to be incomplete. A number of DME methods wh

are on the diagrams (Picture 10 and Picture 11) are not included in the section (6.3.2) on D

methods, or in any other methods section, and, thus, are presumably not among the comma

that may be sent by the application. These methods are: ChangeTool, FindTool, Tool, GoToP

ABCGoToPar, PtMeasPar, and ABCPtMeasPar. Judging from the names (“Par” me

parameter), the missing methods include, among other things, all the methods for setting 

getting parameters. The examples of exchanges between application and DME driver (section 
DME Driver Interface Compar

5

in particular) include calls to some of the missing methods. It may be that the auth

intentionally deleted the methods from section 6.3.2 and did not get around to updating the res

the document, but it seems much more likely that they simply did not complete section 6.3.2

any event, in the absence of a description of what a command does, it is hard to compare 

meaning to anything.

At NIST, we have not heard of any implementations of the I++ DME-Interface having been bu

2.3 Events and Daemons

The I++ DME-Interface includes (in section 4) the notion of an “event”, used in a different se

from the usual meaning in computer programs that deal with events. The usual meaning 

“anything of interest that happened”. In the I++ DME-Interface, an event is a command 

response of high priority. In connection with events, the I++ DME-Interface uses the notion o

“daemon”. A daemon is a thread or subprocess in the DME driver that triggers events.

The CMM-driver Specification does not use events or daemons, but it does provide that so

commands and responses have higher priority than others.

The I++ DME-Interface contains many commands whose names end with an upper case E

seems intended (although nothing explicit regarding command names could be found in the te

that these commands are event commands and the DME driver is expected to generate event

response.

In several cases, the I++ DME-Interface contains pairs of commands whose names differ only 

one having an E at the end and the other not. The descriptions of these commands are identica

seems intended that the command without the E is a normal command, while the command w

the E is an event command.

The remainder of this report does not discuss events. Daemons are not described in detail in 

report but are mentioned where the I++ DME-Interface uses them.
DME Driver Interface Compar

6

3 Issues

This section presents issues involved with the DME driver interface. All but the last two of th

are used in section 4 for comparing the CMM-driver Specification with the I++ DME-Interfac

3.1 Scope

Every interface specification should include a statement of scope describing the domain 

activity to which the specification is intended to apply. The scope should indicate the types 

equipment with which the specification is expected to be usable.

It will be helpful if the scope includes mention of the execution models the standard is intende

support, since some execution models may require more information than others.

For a DME driver interface, the scope should include at a minimum:

1. the activity of dimensional inspection by probing points.

2. the control of CMMs.

3. touch trigger probes.

Other types of dimensional measuring activities and equipment might also be covered, such as

1. scanning probing.

2. control of non-contact optical metrology systems, such as laser scanners, theodolites,

and photogrammetry equipment.

3. non-contact capacitance probes.

3.2 Purpose

Every interface specification should include a statement of purpose describing what capabili

the specification is intended to support. If the interface specification does not state its goals, 

impossible to determine if it achieves its goals.

For a DME driver interface, the purpose should include supporting interoperability and support

DMIS.

3.3 Communications

A DME driver interface specification might include a specification of communications metho

or communications methods might be the subject of a separate specification. If a communicati

method is included, it should be one that is readily available.

3.4 Messaging Protocol and DME Driver States

A messaging protocol (for any message-based interface specification) is a set of rules 

conducting conversations between the sender and receiver of interface commands and respon

This protocol governs which party can send which commands or responses when and what 
DME Driver Interface Compar

7

other party should do about it. Very different behavior may occur in systems using the sa

commands and responses (with well-defined semantics) but a different messaging protocol.

A messaging protocol is not provided by a specification of communications methods. Rather, 

messaging protocol must be built on top of communications methods. A messaging proto

should be included in a DME driver interface specification.

Most provisions of a messaging protocol may be expected to be involved with startup, shutdo

and error handling. Normal steady state operations are likely to be covered by a small portion 

the protocol.

For a messaging protocol to be specified, some method is required for characterizing the condit

of the receiver. The most straightforward way of doing this is to have receiver state variables 

possible values for those variables. Different sets of messages may be sent according to the val

of the receiver’s state variables. State variables of a DME driver might include, for examp

readiness (with values of unready, ready, paused, or erred) and probe_inhibited (with [boole

values of true or false).

3.5 Execution Model

The execution models that a DME driver interface intends to support need to be explicitly sta

in a DME driver interface specification. Two separate aspects of execution models that should 

covered are:

1. whether the DME driver (a) accepts only one command at a time or (b) accepts

multiple commands, puts them in a queue, and manages the queue. If queue

management is expected, commands for queue management are needed.

2. whether the DME driver and application (a) use one-time messaging or (b) use cyclic

messaging.

The first of these is necessarily reflected materially in the messaging protocol. For exam

typically, in case (a) the application should not send a new command until the DME driver retu

a response saying the last command is done, while in case (b) the application may send a n

command as soon as the last command is acknowledged as having been received.

The second of these is also reflected in the messaging protocol, but may be handled simply

cyclic messaging, the application and the DME driver run on a fixed clock cycle and each send

message every cycle. A message may often be identical to the preceding one, except possibly 

an id number. A messaging protocol for one-time messaging may readily be used in a cy

messaging system by considering only messages that are not identical to their predecessors.

There may be other aspects of execution models that are also important; this is not presented as 

exhaustive list.

3.6 Responsibility for Accuracy

A very important issue for users is: who is responsible for the accuracy of measurements taken 

a DME. Is it the DME vendor (who would implement the DME driver), or is it the vendor of 
DME Driver Interface Compar

8

high-level language executor (the application). If the interface allows enough data to pass acr

it, compensations for point data can be made by the application. If the application makes 

compensations, the application vendor is primarily responsible for the accuracy of point data

the interface does not allow enough data to pass across it to support compensatio

compensations can only be made on the DME driver side, and the DME vendor is responsible

The two major types of compensation (not regarding calibration as compensation) are volume

compensation (for measured machine imperfections in specific parts of the work volume) 

thermal compensation (for changes in the machine shape from thermal expansion or contractio

Other types of compensation exist, and some systems may use them.

This issue is also important for third-party software vendors whose software performs correcti

on data points. If the DME driver interface does not support the exchange of the data they ne

they cannot market their products as third parties. They can still attempt to sell their product

vendors to work hidden in the DME driver, but they cannot sell their products directly to users

Additionally, this issue is important for certain non-contact metrology systems which are kno

to put uncompensated point data on the interface. This is particularly important in systems wh

contact and non-contact CMMs work together.

It is important to realize that this issue only regards point data. It does not regard analyzed d

such as feature data (the center and diameter of a circle, for example). The creation of feature d

is outside the scope of the DME driver interface. Feature data is normally created either by 

application (which may well call on third party software) or by a separate analysis package. If 

accuracy of feature data is an issue, both point data and the software used to fit features to po

must be examined.

3.7 Command Set (Coverage and Support for DMIS)

The command set provide by a DME driver interface should be complete within its stated sc

and purpose.

DMIS is the only standard high-level language for control of dimensional measuring equipm

A DME driver interface should support that standard. In particular, a DME driver interface sho

include functionality that makes it possible to carry out all DMIS commands.

Where equipment vendors believe DMIS functionality is unreasonable (there are such areas), 

where I++ members find DMIS in need of improvement, proposals for modifying DMIS sho

be considered. Consideration of proposals for changes to DMIS should have full internatio

participation.

3.8 Message Syntax

The syntax of messages should be completely and unambiguously defined down the individ

character level. By syntax we mean what characters may be used, how they may be combined 

form tokens (words, numbers, etc.) and how tokens and punctuation may be combined to fo

messages.
DME Driver Interface Compar

9

3.9 Semantics

The meaning (semantics) of the commands and responses must be fully described in a D

driver interface specification. If the meanings are not fully specified, the behavior of differ

implementations cannot be expected to be very similar.

Semantics cannot yet be captured fully in any formal language. Unambiguous natural langu

descriptions of meaning are required to accompany any formal specification.

3.10 Language

It is useful if an interface specification is written in a standard information modeling langu

rather than in some ad hoc format. The information model (including the accompanying te

contains all the semantics of the interface. Tools exist for compiling information models written 

standard languages, providing a valuable check on model syntax and completeness. Th

standard information modeling languages are: EXPRESS, CORBA IDL (Common Obj

Request Broker Architecture Interface Definition Language), and XML (eXtensible Mar

Language) schema. C++ classes may also be considered to be an information modeling langua

If a specification is written in an ad hoc format, it cannot be checked automatically for syntax 

completeness errors.

If an information modeling language is used, a method of writing instances of the entities in 

model is needed. The STEP (STandard for the Exchange of Product model data) standard 

XML both provide a file format. With C++ classes, no standard method of writing instance

provided, and the user must invent one. Here again, a standard language has a large advant

over an ad hoc language, in that automatic tools exist that will read and write files of instances 

will check syntax.

3.11 Interoperability

A DME driver interface should support interoperability of dimensional measuring equipment.

In particular, a DME driver interface should make it possible for a high-level controller to con

similarly constructed dimensional measuring equipment using different low-level control

without changing more than configuration files and operating parameters. Standardizing the D

driver interface and conforming to that standard will provide this capability.

Also in particular, a DME driver interface should make it possible, under the same condition

above (same high-level controller, similar equipment, different low-level controllers), to 

nearly identical behavior and inspection results when executing the same high-level progr

Standardizing the DME driver interface and conforming to that standard will also provide 

capability.

As described in section 3.9 and section 3.4, having clear semantics and a clearly defi

messaging protocol in the DME driver interface specification is required for interoperability.

It is desirable that it be possible to execute the same high-level program on different high-le

controllers and get nearly identical behavior and inspection results. Standardizing the DME dr
DME Driver Interface Compar

10

interface and conforming to that standard will make achieving this capability much easier bu

not sufficient. Conformance of the high-level controller to the high-level language is a

required; that is out of the scope of this document.

3.12 Specification Development

Single Specification

The world-wide market for dimensional measuring equipment is too small to benefit fr

competing DME driver interface specifications. Competing specifications lead, obviously

reduced interoperability. This seems likely to be bad for both users and vendors of dimensio

measuring equipment. Vendors and users worldwide should work towards agreement on a sin

standard DME driver interface specification.

To be an international standard, the DME driver interface should be made an ISO standard. If 

DME driver interface is made a national standard of two or more countries before be

considered by ISO, differences in the national versions will inevitably arise that will make it m

difficult to agree on a single ISO version.

Specification Validation

Like a computer program, a technical standard such as the DME driver interface cannot 

expected to be correct until it is thoroughly tested and debugged. If anyone suggested writin

large new computer program by committee consensus and then selling it without compiling it 

without testing it, he or she would be considered marginally insane. Nevertheless, standards 

usually developed by committee consensus and often become national or international standa

with little or no testing.

Any DME driver interface should be thoroughly tested and debugged before it is agreed to us

commercially and before it becomes a standard of any sort.

Conformance

After a DME driver interface is standardized, the issue of conformance to the standard becom

important, but that is outside the scope of this report.
DME Driver Interface Compar

11

4 Comparison of Broad Areas

This section provides a broad comparison of the CMM-driver Specification and the I++ DM

Interface.

In the tables in this report, section numbers of the CMM-driver Specification and the I++ DM

Interface are included inside parentheses, (3.2.5) for example. An X in a table means the i

does not exist. Comments in the tables are given in helvetica type.

4.1 Scope

The scope of the CMM-driver Specification is given on five lines. These lines provide that to

trigger sensors, spherical probe tips, 3 axes CMMs, and 2 axes probe heads are in scope.

The scope of the I++ DME-Interface is cartesian coordinate CMMs.

Neither document discusses what execution models are intended to be supported.

4.2 Purpose

Both the CMM-driver Specification and the I++ DME-Interface give no purpose at all. Neit

makes any explicit commitment to supporting interoperability and neither makes any commitm

to supporting the functionality available within DMIS or any other high-level language.

Both need to have an explicit statement of purpose added.

4.3 Communications

The CMM-driver Specification states briefly that sockets should be used.

The I++ DME-Interface states that TCP/IP sockets will be used for communications. Section 3 

the document (e.g., picture 4 in section 3.1), however, indicates that communications is a la

separate from the client (application) and server (DME driver), so that communications migh

changed in the future.

The two documents agree on communications.

It might be preferable if specifying the method for communicating were separate from the res

the DME driver interface specification. This would allow one to be changed without affecting 

other. A specification of both is needed in order to build a working system, of course, so this is 

a major consideration. Since communications is an area of agreement between the 

documents, it may be best to leave it alone.

4.4 Responsibility for Accuracy

The two documents differ regarding the responsibility for accuracy.
DME Driver Interface Compar

12

The CMM-driver Specification provides commands that allow compensation to be made on eit

side of the interface. We have not tried to determine if these are adequate to serve the need

third-party software vendors.

The I++ DME-Interface states specifically in section 1.4 that “the DME vendor is responsible 

the accuracy of his measurement equipment, in the sense that all necessary functions related to 

equipment accuracy have to be implemented in the [DME-I]”. This implies that there should 

no interface functions intended to support making accuracy compensations outside the DME

and none are provided.

One way the difference between the two documents might be resolved is to provide in 

specification that there should be two conformance classes, one that includes the comma

necessary to do compensation in the application, and one that does not. A DME vendor wo

declare in which conformance class the vendor’s system lies. The user could decide which clas

buy.

4.5 Command Set (Coverage and Support for DMIS)

The command set provided by the CMM-driver Specification appears to be adequate to supp

almost all of the functionality expected of a CMM with a touch trigger probe. It also appears to 

adequate to support a large portion of DMIS.

As noted earlier, the command set provided by the I++ DME-Interface appears to be incompl

Even if all the methods mentioned anywhere in the document were added to the protocol (sect

6), important pieces would be missing, such as access to almost all configuration data.

If and when other types of equipment and sensors are added to the scope, additional comma

will be needed to support them.

4.6 Messaging Protocol and DME Driver States

The messaging protocols of the CMM-driver Specification and the I++ DME-Interface 

similar. Neither one, however, is adequately defined. Neither one has DME driver states or 

other method of specifying which messages may be sent under what conditions.

In both messaging protocols, the usual exchange starts when the application sends a comma

the application must then wait for an acknowledgement from the DME driver that the comm

has been received before sending another command. On receiving a command, the DME dr

sends an acknowledgement and puts the command on its queue of commands to execute. Whe

finishes executing a command, the DME driver sends a done message. In the CMM-dri

Specification, the done message often includes returned data. In the I++ DME-Interface, the d

message contains no data (done is just plain done), and if data is to be returned, it is returned 

separate message sent before the done message. The name of the done message in the I++ DM

Interface is “ready”, but all it means is that execution of the indicated command is over (eit

because it was completed successfully or because it was aborted). In the CMM-dri

Specification, done means completed successfully.
DME Driver Interface Compar

13

Both documents provide that some messages have higher priority than others. Dealing w

commands of different priority in a queuing system is very tricky. Both documents are quite va

about how this is to be done and need major improvement. Defining DME driver states should 

useful in connection with handling commands with different priorities.

The I++ DME-Interface specifies that, except for responses identified as events, the DME dr

must handle commands in the order received, and must send all messages responding to 

before sending any data, error, or done messages responding to the next one. Acknowledgem

messages, however, may be sent at any time, and actual execution of commands may overlap.

The CMM-driver Specification specifies only that the application must wait until it receives 

acknowledgement or error message from the DME driver before sending another comma

Additional responses to a command may be sent in any order, and commands are not required 

be carried out in order. The CMM-driver Specification may intend that certain commands (such 

MOVE_AXIS) be carried out in order. If so, it should be changed to make such cases explici

not, it should include a warning to application builders.

The handling of command identifiers differs between the two documents. In the CMM-dri

Specification, the DME driver assigns them. In the I++ DME-Interface, they are assigned by 

application. Having them assigned by the application is preferable, stemming from the fact 

the application is the party that creates the command.

The I++ DME-Interface goes a little beyond the CMM-driver Specification in the case 

commands for which multiple responses are expected. For such commands, the I++ DM

Interface specifies that a daemon should be created that causes messages to be sent periodica

Commands for stopping daemons are provided.

The I++ DME-Interface provides a number of examples of message “conversations” between 

application and the DME driver. This is a very useful feature of the I++ DME-Interface. T

CMM-driver Specification provides no examples.

4.7 Message Syntax

The CMM-driver Specification syntax specification is loose and needs tightening. It allo

characters that are not recognized in the syntax to be included in messages. This is very unwis

that it allows errors to slip through and allows implementations to hide proprietary messa

inside DME driver interface messages. The occurrence of an unrecognized character sho

always be considered an error. The CMM-driver Specification does not define types of data 

how data of each type should be written in messages; it should do that.

The I++ DME-Interface syntax specification does not explicitly allow characters not in 

syntax, but is otherwise slightly looser. In addition to not defining data types, it provides 

description at all of numbers or command arguments, which the CMM-driver Specification d

provide.
DME Driver Interface Compar

14

A good syntax specification would be written in a syntax specification language such as Exten

Backus Naur Format (EBNF). That would prevent arguments about what syntax is legal, si

such languages specify syntax down to the individual character level.

4.8 Semantics

As noted in the issues, complete semantics are essential for interoperation. Both specificati

need improvement in semantics.

The CMM-driver Specification is very weak on semantics. It rarely devotes more than a phras

the meaning of a command. Descriptions of other items are often sketchy. Some important ite

are given no description at all.

The I++ DME-Interface is fair on semantics. Certain commands, such as PtMeas, are thoroug

described, while others, such as Abort, have brief, incomplete descriptions.

4.9 Language

The notation used in the CMM-driver Specification for describing syntax is non-standard. T

document does not explicitly describe the notation. It would be useful if it did so.

The I++ DME-Interface uses an ad hoc method of describing the format of messages, but u

C++ function format for most of the contents of messages.

Neither document takes full advantage of modern information modeling techniques, but it m

make reaching agreement on a single standard easier if ad hoc methods continue to be used.

4.10 Execution Model

Neither the CMM-driver Specification nor the I++ DME-Interface describes explicitly 

execution models that it intends to support. Both clearly expect the DME driver to maintai

queue of pending commands, but neither says much about queue management. Neither menti

cyclic messaging.
DME Driver Interface Compar

15

KEY: In this table and all other tables in this report, section numbers of the CMM-dri

Specification and the I++ DME-Interface are included inside parentheses, (3.2.5) for example. 

X in a table means the item does not exist. Comments in the tables are given in helvetica type

Table 1: Broad Areas

Issue CMM-driver Specification I++ DME-Interface

Scope (3.1)

touch trigger sensors,

spherical probe tips, 3 axes

CMMs, and 2 axes probe

heads are in scope

Not explicit, but implied by

figures and C++ code, particular

Pictures 10 and 11.

cartesian coordinate CMMs

are in scope

Purpose none explicitly stated none explicitly stated

Communications (3.2.1)

use sockets

(3.1)

use TCP/IP sockets

Responsibility for

Accuracy

(no specific section)

allows either application side

or DME driver side (DME

vendor) to be responsible for

accuracy

(1.4)

only DME vendor may be

responsible for accuracy

Command Set

(Coverage and

Support for DMIS)

(4) twenty-one pages.

complete or almost complete

for CMMs with touch trigger

probes, supports much of

DMIS

(6) twenty pages.

incomplete

Messaging Protocol

and DME Driver

States

(3.2)

messaging protocol not clearly

described.

no DME driver states provided.

(6.1 & 6.2)

messaging protocol not clear

described.

no DME driver states provide

Message Syntax syntax needs tightening syntax needs tightening

Semantics needs major improvement needs improvement

Language ad hoc ad hoc with C++

Execution Model not explicit, queuing expected not explicit, queuing expected
DME Driver Interface Compar

16

5 Detailed Comparisons

This section provides a detailed comparison of the CMM-driver Specification and the I++ DM

Interface. Each subsection focuses on one topic. Most of the topics are types of commands. E

subsection has text at the beginning and a table at the end.

In several cases, the I++ DME-Interface contains pairs of commands with identical names 

one has an empty argument list and the other has a non-empty argument list. This (alas

standard practice in object-oriented languages. These are different commands. The command w

the empty argument list is generally a “get” command that gets the value of something, while 

one with the non-empty argument list is a “set” command that assigns a value to the same thin

5.1 Administrative Commands

Administrative commands deal with starting to use the DME driver interface, stopping using 

dealing with errors, and dealing with a queue of unfinished commands, some of which may 

executing, and others of which have not yet been started.

Both documents assume that the DME driver may maintain a queue of accepted commands.

The CMM-driver Specification is weak regarding queue handling. The I++ DME-Interfac

better but needs further tightening.

The I++ DME-Interface defines the notion of a session. The CMM-driver Specification does n

Session is a useful notion and should be defined.
DME Driver Interface Compar

17

Table 2: Administrative Commands

What Command Does CMM-driver Specification I++ DME-Interface

stops executing one

currently executing

command

ABORT (4.1.1) StopDaemon (6.3.1.3)

stops executing all

currently executing

commands

StopAllDaemons (6.3.1.4)

removes pending

commands from the

queue

Abort (6.3.1.5)

It is not clear whether

commands that have been

started are considered

pending, or only commands

that have not been started, o

both.

clears any and all errors CLEAR_ERROR (4.1.2) ClearAllErrors (6.3.1.6)

stops accepting DME

driver interface

commands

CLOSE_DRIVER (4.1.3) Disconnect (6.3.1.2)

pauses or resumes

accepting DME driver

interface commands

CMM_DRVR (4.1.4)

Proprietary commands may

be sent while accepting DME

driver interface commands is

paused.

X

obtains status of DME

driver

GET_STATUS (4.1.6) ErrStatus (6.3.2.11)

ErrStatusE (6.3.2.12)

obtains more detailed

status of DME driver

X XtdErrStatus (6.3.2.13)

begins accepting DME

driver interface

commands

INIT_DRIVER (4.1.5) Connect (6.3.1.1)

resets all parameters to

default values

RESET (4.1.7) X
DME Driver Interface Compar

18

5.2 Commands that Change Responses

The CMM-driver Specification has mostly fixed specifications for what information should 

included in responses to commands and provides few commands that change what should 

included.

The I++ DME-Interface has more modifiable specifications for what information should 

included in responses to commands and provides more commands that change what should 

included.

5.3 Free Space Motion Commands

The free space motion commands of the two documents are very similar, except that the I

DME-Interface provides a command to ask if the machine is homed, which is not provided by 

CMM-driver Specification.

Table 3: Commands that Change Responses

What Command Does CMM-driver Specification I++ DME-Interface

specifies what should be

reported after executing

GoTo

X OnEndOfGoToReport

(6.3.2.6)

types of “properties

and “methods” need t

be better described

specifies what should be

reported on executing

PtMeas

SET_PARAMETER

(TOUCH_REPORT)

(4.9.10)

OnPtMeasReport

(6.3.2.7)

specifies what should be

reported while executing

GoTo

SET_PARAMETER

(TIMED_POSITION_REPORT)

(4.9.9)

OnMoveReportE

(6.3.2.8)

specifies what should be

reported when the joystick is

enabled and the user uses the

joystick to move the

machine

OnManualMoveReportE

(6.3.2.9)
DME Driver Interface Compar

19

5.4 Probing Commands

As noted earlier, commands for activating tools have been omitted (apparently inadverten

from the I++ DME-Interface. It is not clear why there is no explicit command to measure a po

manually. The EnableUser command (6.3.2.3) is certainly intended to allow man

measurements, but the OnManualMoveReportE command (6.3.2.9) does not seem to provid

means to distinguish way points from hit points.

Table 4: Free Space Motion Commands

What Command Does CMM-driver Specification I++ DME-Interface

gets the current position

of axes

GET_POS (4.3.1) Get (6.3.3.13)

GetE (6.3.3.14)

moves to home position HOME (4.3.2) Home (6.3.2.1)

moves to specified

position

MOVE_AXIS (4.3.3) GoTo (6.3.3.15)

determines if the

machine is homed

X IsHomed (6.3.2.2)

It is not clear whether a machin

is considered to be homed only

when it is at home position or a

all times during a session

following successful execution o

the Home command.

Table 5: Probing Commands

What Command Does CMM-driver Specification I++ DME-Interface

manually measures a point PROBE_MAN (4.4.1) X

automatically measures a

point

PROBE_TO (4.4.2)

Weak semantics.

PtMeas (6.3.3.16)

Strong semantics.

activates named probe tip ACTIVATE_SENSOR (4.5.1) X

activates or deactivate

current probe tip

INHIBIT_PROBE (4.5.2) X
DME Driver Interface Compar

20

5.5 Multiple Carriage Commands

The I++ DME-Interface does not deal with multiple carriages. Section 1.6 says they will 

added between releases 1.0 and 1.1.

5.6 Calibration Commands

The CMM-driver Specification provides three calibration commands. These make it possible 

implement DMIS commands for calibration.

The I++ DME-Interface provides no calibration commands. Calibration commands do not m

it possible to perform compensations outside the DME driver, but their existence would be a li

contrary to the notion that the DME vendor should be responsible for accuracy (see section 

and section 4.4). Presumably, the DME driver is expected not to be ready to go until 

calibrations are complete. It would be pointless to include a command to do something that m

already have been done.

Table 6: Multiple Carriage Commands

What Command Does CMM-driver Specification I++ DME

Interface

turns on or off the automatic coupling of

carriages

COUPLING (4.2.1) X

gets the transformation that controls how

two carriages will be coupled when they

are coupled

GET_COUPLING_DATA (4.2.3)

Semantics unclear.

X

sets the transformation that controls how

two carriages will be coupled when they

are coupled

SET_COUPLING_DATA (4.2.2)

Semantics unclear.

X

Table 7: Calibration Commands

What Command Does CMM-driver Specification I++ DME

Interface

calibrates a tip on the current sensor

assembly

CALIBRATE (4.5.3) X

defines the shape of the artifact used for

calibrating sensors

DEF_CALIB_ARTIFACT (4.5.5) X

starts a calibration sequence START_CALIB_SEQUENCE

(4.5.4)

X
DME Driver Interface Compar

21

5.7 Miscellaneous Commands

This section includes those commands for which there is only one or two of a type.

5.8 Coordinate Systems

The CMM-driver Specification requires the use of machine coordinates at all times (correcte

correction is available). The point whose coordinates are given, however, may always be either 

a point in a fixed location with respect to the ram or (b) the point at the center of the probe tip. T

CMM-driver Specification does not allow any other coordinate systems for axis data in comma

or responses. The CMM-driver Specification does allow the coordinate system for the digital r

out to be changed and the coordinate system for the joystick to be changed.

The I++ DME-Interface allows the application to select one of three coordinate systems: 

MachineCsy (machine coordinate system), the MultipleArmCsy (multiple arm coordin

system), or the PartCsy (part coordinate system). Set and get methods are provided for the p

coordinate system.

Table 8: Miscellaneous Commands

What Command Does CMM-driver Specification I++ DME-Interface

loads and activates a sensor

assembly

LOAD_ASSM (4.6.1) X

unloads a sensor assembly UNLOAD_ASSM (4.6.2) X

disables joystick control SET_AUTO_MODE (4.11.1) DisableUser (6.3.2.4)

enables joystick control SET_MAN_MODE (4.11.2)

Control by command works

while in manual mode.

EnableUser (6.3.2.3)

determines whether

joystick control is enabled

X IsUserEnabled (6.3.2.5)

gets data about a rotary

table

GET_TABLE_DATA (4.12.1) X
DME Driver Interface Compar

22

5.9 Settable Parameters

Settable parameters are parameters that may be set by a DME driver interface command. They 

used by the low-level controller for rates, distances, time intervals, etc. used in its operation.

There is no point in being able to set a parameter if it is not used by the low-level controller. 

interoperability, the meaning of each parameter and the use made of each parameter must be fu

described in the interface specification.

Both documents are extremely inadequate in regard to settable parameters.

For most of the settable parameters, the CMM-driver Specification contains no description 

what they mean and no reference is made to them outside of the description of commands that 

and set them. The parameters for which this is the case include: approach_dist, measuring_fo

moving_accel, probing_accel, retract_dist, and search_dist. In addition the syntax is unclear 

moving_speed, moving_accel, probing_speed, and probing_accel. For all four of those, a phr

Table 9: Coordinate Systems

What Command Does CMM-driver Specification I++ DME-Interface

sets the coordinate system

with respect to which

digital read-out (DRO)

coordinates are given

SET_DRO_MATRIX

(4.10.1)

X

The PartCsyTransformation

with argument command

presumably has this effect.

sets the coordinate system

with respect to which jog

moves are made

SET_JOG_MATRIX

(4.10.2)

X

The PartCsyTransformation

with argument command

presumably has this effect.

selects one of three

coordinate systems as the

current coordinate system

X CoordSystem

with argument (6.3.3.1)

gets the identity of the

coordinate system

currently in use

X CoordSystem

no argument (6.3.3.2)

sets the transformation

giving the location of the

part coordinate system

X PartCsyTransformation

with argument (6.3.3.4)

gets the transformation

giving the location of the

part coordinate system

X PartCsyTransformation

no argument (6.3.3.3)
DME Driver Interface Compar

23

such as “percentage of maximum (0.7 is 70%)” is used, which might mean either “use the str

‘0.7’ and that will mean 70 percent”, or “use the string ‘70%’ and that will mean 0.7”.

As noted earlier, the I++ DME-Interface has omitted (apparently unintentionally) availa

commands for getting and setting parameters. The I++ DME-Interface does, however, provid

good description of how approach distance, search distance, and retract distance are used 

executing the PtMeas command.
DME Driver Interface Compar

24

Table 10: Settable Parameters

Normal Use of Parameter Name in CMM-driver

Specification Name in I++ DME-Interface

distance from target point

at which to start probing

move

approach_dist

No semantics.

X

tool()->Approach() method

mentioned, page 42, but no method

defined. _Approach data member

listed in 9.5.6.

distance by which sensor

path may deviate from the

programmed path during

free space moves

fly_mode

Semantics fair.

X

force on probe at which a

hit should be recorded

measuring_force

No semantics.

X

rate of acceleration for

free space moves

moving_accel

No semantics,

Accel for GoTo (5.3 & 9.5.5)

speed at which to move in

free space

moving_speed

Semantics weak.

Speed for GoTo (5.3 & 9.5.5)

rate of acceleration for

probing moves

probing_accel

No semantics.

Accel for PtMeas (5.3 & 9.5.6)

speed at which to move

while probing

probing_speed

Semantics weak.

Speed for PtMeas (5.3 & 9.5.6)

distance to back off after

probe hit

retract_dist

No semantics.

X

tool().Retract() method mentioned,

page 42, but no method defined.

_Retract data member listed in 9.5.

distance past target point

at which to stop probing

move if no hit

search_dist

No semantics.

X

tool()->Search() method mentioned

page 42, but no method defined.

_Search data member listed in 9.5.

time interval at which to

report position

timed_pos_report

Semantics OK.

No system parameter, but is

parameter of OnMoveReportE

axes whose position is set

when a touch occurs

touch_report

Semantics OK.

No system parameter, but is

parameter of OnMoveReportE
DME Driver Interface Compar

25

5.10 Settable Parameter Commands

Settable parameter commands are for obtaining the values of parameters, obtaining the allow

values of parameters, and setting parameters. The parameters themselves are listed in 

immediately preceding table.

The CMM-driver Specification is a little odd regarding command settable parameters. Eight of 

eleven parameters can be set and obtained and their allowable values can be obtain

Probing_acceleration can be obtained and its allowable values can be obtained, but it cannot 

set. Fly_mode and touch_report can be set but not obtained and their allowable values cannot 

obtained. No explanation is given for this oddity, and it may simply be an oversight.

As noted earlier, the I++ DME-Interface has omitted (apparently unintentionally) availa

commands for getting and setting parameters, except in the case of parameters relating to 

GoTo, EnableUser, and PtMeas commands.

5.11 Commands for Getting Configuration Data

Configuration items are pieces of information that can be obtained but not set by DME dr

interface commands. This is information about the physical machine or the software being used 

some aspect of the current mode of use.

The CMM-driver Specification provides one command, GET_CONFIG, to get configuration d

This command may take the name of any of twenty configuration items as an argument.

The I++ DME-Interface provides one command that gets one of the twenty items of configurat

data specified in the CMM-driver Specification.

The CMM-driver Specification provides many more types of configuration data, most or al

which appear to be useful, so its provisions appears preferable.

Table 11: Settable Parameter Commands

What Command Does CMM-driver Specification I++ DME

Interface

gets the value of a named parameter GET_PARAMETER (4.7) X

gets the allowable values for a named

parameter

GET_PARAMETER_INFO (4.8) X

sets the value of a named parameter SET_PARAMETER (4.9) X
DME Driver Interface Compar

26

Table 12: Commands for Getting Configuration Data

Configuration Item CMM-driver Specification I++ DME

Interface

word size of controller

(8 bit, 16 bit, 32 bit, or other)

GET_CONFIG(CONTR_TYPE)

(4.13.1)

X

CNC capability of DME

(manual or CNC)

GET_CONFIG(CNC_TYPE)

(4.13.2)

X

control panel type GET_CONFIGC(PANEL_TYPE)

(4.13.3)

X

double column mode

(on or off)

GET_CONFIG(DCOL_MODE)

(4.13.4)

X

double column number

(number of current column)

GET_CONFIG(DCOL_NUMBER)

(4.13.5)

X

type of head

(fixed, indexed, or servoed

GET_CONFIG(HEAD_TYPE)

(4.13.6)

X

CMM type GET_CONFIG(MACHINE_TYPE)

(4.13.7)

Type

(6.3.2.10)

number of probe changers

(may be zero or positive)

GET_CONFIG(NUM_PRB_CHANGERS)

(4.13.8)

X

data for one probe changer GET_CONFIG(PRB_CHANGER_DATA)

(4.13.9)

X

code number of product provider GET_CONFIG (PROVIDER)

(4.13.10)

Only choices are B&S, LK, Zeiss.

X
DME Driver Interface Compar

27

5.12 Tool and Tool Changer Data Commands

Tool data commands create or remove data about tips, sensors, and tool assemblies. Th

commands produce no motion of the tools. The CMM-driver Specification provides a la

number of tool data commands. As mentioned earlier, the I++ DME-Interface, proba

inadvertently, provides none.

The CMM-driver Specification provides three commands for dealing with tool changer data. T

I++ DME-Interface provides none. Commands for actually changing tools, not just getting 

setting data, are covered in section 5.7 of this report.

revision number of product GET_CONFIG (REV_NUMBER)

(4.13.11)

Does not specify what product the

number is for when no product name

is given.

X

whether the machine has a rotary

table (0 or 1)

GET_CONFIG (ROTARY_TABLE)

(4.13.12)

X

whether switching to scale

coordinates is possible (0 or 1)

GET_CONFIG(SCALE_COORDINATES)

(4.13.13)

X

current sensor type GET_CONFIG(SENSOR_TYPE)

(4.13.14)

X

whether temperature

compensation is enabled (0 or 1)

GET_CONFIG(TEMP_COMP)

(4.13.15)

X

whether the CMM being

controlled is real or simulated

GET_CONFIG(USE_MODE)

(4.13.16)

X

whether a direction vector is

returned with touch points (0 or 1)

GET_CONFIG(TOUCH_VECTOR)

(4.13.17)

X

total number of machine axes GET_CONFIG(NUM_AXES)

(4.13.18)

X

detailed information about one

axis

GET_CONFIG(AXIS_DATA)

(4.13.19)

X

order in which axis moves are

made

GET_CONFIG(AXIS_SYNCH_GROUPS)

(4.13.20)

X

Table 12: Commands for Getting Configuration Data

Configuration Item CMM-driver Specification I++ DME

Interface
DME Driver Interface Compar

28

Table 13: Tool Data Commands

What Command Does CMM-driver Specification I++ DME

Interface

gets a list of the names of all available

sensor assemblies

GET_ALL_ASSM (4.14.1) X

gets a list of the names of all available tips

in one named sensor assembly

GET_ALL_TIP (4.14.2) X

gets a list of the names of all calibration

positions of one named tip in one named

sensor assembly

GET_ALL_SENSOR (4.14.3) X

gets whether an assembly is analog,

trigger, or hard

GET_ASSM_DATA (4.14.4) X

gets data on one named tip in one named

sensor assembly

GET_TIP_DATA (4.14.5) X

gets data on one named tip and sensor in

one named sensor assembly

SET_SENSOR_DATA (4.14.6) X

gets data on a named sensor assembly GET_TOOL_ASSM (4.14.7) X

sets calibration data for an existing

nominal sensor in a named sensor

assembly for a named tip (thereby creating

an actual sensor)

CREATE_SENSOR_ACTUAL

(4.14.8)

X

sets data for a nominal sensor not already

in a named sensor assembly for a named

tip, and adds the nominal sensor to the

assembly

CREATE_SENSOR_NOMINAL

(4.14.9)

X

sets data for a tip not already in a named

sensor assembly, and adds the tip to the

assembly

CREATE_TIP (4.14.10) X

sets data for a new sensor assembly CREATE_ASSM (4.14.11) X

deletes data for a named sensor assembly DELETE_ASSM (4.14.12) X

deletes a named tip from a named sensor

assembly

DELETE_TIP (4.14.13) X

deletes a named sensor from a named

sensor assembly for a named tip

DELETE_SENSOR (4.14.14) X
DME Driver Interface Compar

29

5.13 Multiple Messages, Unsolicited Messages, and Error Messages

In both the CMM-driver Specification and the I++ DME-Interface, multiple messages may 

sent by the DME driver in response to a DME driver command requiring an unspecified num

of response messages. The CMM-driver Specification calls these “unsolicited” messages; the I

DME-Interface does not call them unsolicited. The multiple shot commands of the I++ DM

Interface all lead to multiple responses.

Both the CMM-driver Specification and the I++ DME-Interface, provide that the DME dr

may at any time send an error message. An error message may or may not identify a command

the error cannot be identified with the execution of a command, the error message does 

identify a command; both documents regard the error message as unsolicited in this case.

The CMM-driver Specification but not the I++ DME-Interface provides that unsolicited messa

TOUCH, POSITION, and KEY may be sent “by the DME driver when teaching an inspect

program” (and not under control of the application). The CMM-driver Specification does 

explain how the application is informed that teaching is in progress.

Both documents identify errors that may occur and assign codes to them. The CMM-dri

Specification provides a list of assigned codes. The I++ DME-Interface does not. Both docume

need improvement in identifying all errors that may occur in executing each command. For m

commands where errors may occur, the CMM-driver Specification does not list any poss

errors.

In the following table, the I++ DME-Interface data response message (denoted by #) is listed 

being equivalent to various specific CMM-driver Specification messages. This equivalence is o

Table 14: Tool Changer Data Commands

What Command Does CMM-driver Specification I++ DME

Interface

gets data regarding the relationship

between a tool changer and a tool

assembly

GET_CHANGER_DATA (4.15.1) X

adds data establishing a relationship

between a tool changer and a tool

assembly

CREATE_CHANGER (4.15.2) X

deletes data regarding a relationship

between a tool changer and a tool

assembly, thereby removing the

relationship

DELETE_CHANGER (4.15.3) X
DME Driver Interface Compar

30

rough. The I++ DME-Interface is definitely the weaker of the two in regard to reporting d

generated by a user on the DME driver side. It does not, for example, provide any explicit met

of reporting which key has been hit. It is also not clear how to distinguish a user-generated to

point from a user-generated way point.

Table 15: Multiple Messages and Error Messages

What Message Does CMM-driver Specification I++ DME-Interface

reports a touch point TOUCH (5.2) # (6.2.2.2 & 6.2.2.3)

reports current

position while in

manual mode

POSITION (5.3) # (6.2.2.2 & 6.2.2.3)

reports the state of a

control panel key

pressed by the user

KEY (5.4) # (6.2.2.2 & 6.2.2.3)

reports current

position at fixed time

and/or distance

intervals

DRO_POS (5.5) # (6.2.2.2 & 6.2.2.3)

reports that an error

has occurred

ERROR (6.2) ! (6.2.2.2 & 6.2.2.3)