# Integrated Comments on Release 1.30 of the I++ DME Interface Specification

Date: June 30, 2003

This document is in two parts. The first presents substantive comments
on the spec and the second presents merely minor editorial comments.

Part 1:

Technical and non-Minor Editorial Comments on Release 1.30

of the I++ DME Interface

T. Kramer

June 30, 2003

These are the combined comments of NIST personnel and participants in
the

biweekly conference call about the I++ DME interface. If the person who

prepared a comment is not T. Kramer, the person is named with the
comment.

The comments without names are due to T. Kramer. The first nine comments

are not page-specific. Starting with comment 10, page numbers of the

document are given and the comments are in page number order.

Many of the comments made by T. Kramer on version 1.09 and version 1.1

of the spec were satisfied by changes made while preparing version 1.30.

It is very gratifying that this was done. Some of the comments below

are the same as comments made on earlier versions which were not

satisfied in version 1.30.

Swen Haubold

1\. General

\-\-\-\-\-\-\-\--

In many aspects the specification is not consistent through the
different chapters and examples. Some parts of the specification seem to
already cover not scheduled extensions.  In some cases there are
differences between the object model and the description. Also it is not
clear whether the written specification or the object model shows the
correct interface. I will try to cover most of the problems here but the
list may

not be complete. From my point of view the specification should be
completely revised before any enhancements of the protocol. Also some
parts of the specification seem to cover the hardware of a specific
vendor and therefore do not provide a complete abstraction layer.

Swen Haubold

2\. Parameter lists

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

In many cases the specification does not describe the possible
parameters in detail. There is very often vague phraseology like: \'or
any other methods that may change something\'. This will cause problems
with the interoperability of the implementations because it depends on
the implementation which parameters in detail are allowed, beside the
one

mentioned for the command.

Swen Haubold

3\. Error handling

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The different chapters and examples of the specification provide
different information about the error handling. Chapter 6.2.5 states
that in case of any error the server will abort all actions and the
client must call ClearAllErrors to continue. In chapter 8.1 in the
description of the parameter F1 there is the statement, that only errors
with classification

higher or equal 2 require ClearAllErrors. In contradiction the example
6.2.3.1 shows no error handling at all for an error of severity class 3!

Especially the handling of errors with severity class 0 and 1 is not
clear. Based on my understanding the server simply continues without any
special action, but the handling of the pending commands is not
described.

Swen Haubold

4\. Missing items

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Probe handling -

The complete probe handling is done at the server layer. The probe
compensation is done at the client layer. Unfortunately the server model
does not provide a property to retrieve the probe diameter for probe
compensation.

Protocol (specification) version -

The current implementation does not provide any information of the
supported specification version. This should be available as a standard
property to make the self-configuration of the client easier. Otherwise
this must be done by a command and error (not supported, syntax error)
approach.

5\. Purpose

\-\-\-\-\-\-\-\-\--

The document does not adequately explain what its purposes are. If the
document does not say what capabilities the interface is intended to
provide: (a) users will not know what it is supposed to be good for, and
(b) it will not be possible for anyone but the authors to determine if
the interface provides the capabilities it is intended to provide.

Currently, the purpose is given only the sentence \"The spec is created
to have a common interface to give the possibility to connect different
application packages to all DMEs.\". This is a significant improvement
over version 1.1 but is still not sufficient.

A leading CMM application developer has stated that it is important to
his customers (and therefore to him) that they have to learn how to use
only a single user interface. If the I++ DME-Interface does not provide
the capability to run the DME manufacturer\'s calibration routines from
the application\'s user interface, it will not be possible for the
application developer to meet his users\' needs. The document should
state explicitly whether it intends to support running the DME
manufacturer\'s calibration routines via the I++ DME-interface.

An important capability for system builders is plug-compatibility (also
called plug and play). The idea of plug-compatibility is that it should
be possible (a) to have a given server be able to run the same software
regardless of what the client application is, and (b) to have a given
application be able to run the same software regardless of what the
server is. The I++ DME-interface does not say whether it intends to
support plug-compatibility. It should explicitly say whether it does or
not.

6\. Normative vs. Non-Normative Material

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It is not clear how much of the document is intended to be normative. 
For

the interface to work, only (1) communication methods (2) messages sent

by the client, including their meanings, and (3) responses sent by the

server, including their meanings, need be specified. The internals of
the

server need not be specified. In particular, there does not seem to be
any

reason to make the object models of section 5 be normative. It would be

better to move the object models to an appendix.

7\. Parameters and Arguments

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The document uses the word \"parameters\" in two senses: (a) the
parameters

of a method call, and (b) system or tool parameters. The document uses

the word \"argument\" as a synonym for the first meaning of parameter in

Sections 6.3 (first paragraph), 6.3.1.9, 6.3.1.11, 6.3.2.3, 6.3.2.11,

6.3.2.12, 6.3.2.13, and 6.3.3.5 through 6.3.3.12.

It is confusing to have two meanings for \"parameter\". It is also
confusing

to have two words that mean \"argument\". The best way to fix this would
be

to use \"parameter\" only for system or tool parameters, and to use

\"argument\" only to mean the arguments of a method. To implement this,
it

would be necessary to change \"parameter(s)\" to \"argument(s)\" in
several

dozen places. This would not be hard to do.

For example, in Section 6.3.1.12, the third line, which currently is

\"Parameters   A pointer to a object, e.g. parameter block\", would be

changed to \"Arguments   A pointer to an object, e.g. parameter block\".

As another example, the third line of Section 6.3.1.9, which is now

\"Parameters   An enumeration of one or more of the following methods
can

be argument.\" would be changed to \"Arguments   The argument list is an

enumeration of one or more of the following methods.\".

In the error messages defined in Section 8.2, it appears that in all
cases

where \"parameter\" is used, it is meant in the sense of \"argument\". 
Thus,

everywhere \"parameter\" appears in an error message, it should be
changed to

\"argument\".

8\. Format of Responses

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The formats for data responses are irregular and should be made regular.

The formats for commands all follow the pattern \<command
name\>(\<something\>).

The formats for responses follow no single pattern. Rather, there appear

to be three patterns plus non-patterned responses. The three patterns

are:

a\. response looks like command with data added. There are four

   instances: GetMachineClass, GetCsyTransformation, IsHomed,

   and IsUserEnabled.

   Example Response: IsHomed(0)

         for command IsHomed()

b\. response looks like command with \"Get\" removed and data added.
There

   are two instances: GetCoordSystem, GetErrStatus.

   Example Response: CoordSystem(PartCsy)

      for command GetCoordSystem()

c\. response looks like command with command name and parentheses
removed

   and data added. There are three instances: Get, GetProp, GetPropE

   Example Response 1: X(30), Y(-8.2)

       for command Get(X(), Y())

   Example Response 2: Tool.PtMeasPar.MinAccel(2.0)

   for command GetProp(Tool.PtMeasPar.MinAccel())

It would be helpful (especially for response parser builders), if
responses

followed a single simple pattern.

One possible pattern is make the response name for data by removing
\"get\"

from the beginning of the command name (if it starts with \"get\") and
adding

\"data\" at the end. The response would have the same parentheses as the

command. Using this method, the four examples above might become:

  IsHomedData(0)

  CoordSystemData(PartCsy)

  PtData(X(30), Y(-8.2))

  PropData(Tool.PtMeasPar.MinAccel(2.0))

A second way to do it would be to always omit the command name or
anything

like it. Since the command tag is provided with the response, the client

will know what the command name was.

If the command name does not appear in the response, parentheses around
the

remainder of the response could be used or not used.  The use or non-use
of

parentheses should, however, be the same for all data responses.

9\. Parentheses in Section Headings

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This is a minor but broad editorial comment.

The document is inconsistent regarding whether section headings which
are

command names include parentheses. Parentheses are included in Section
6.3

\[for example: \"6.3.3.1 SetCoordSystem(..)\"\], but they are not
included in

Section 11 \[for example \"11.1.2 OnScanReport\"\] or in Section 12
\[only

instance \"12.1 AlignPart\"\].  It would be cleanest to eliminate the

parentheses from all section headings. The table of contents will need
to

be updated if this is done. No information will be lost if the
parentheses

are eliminated in headings, since each section indicates what arguments
are

required. Alternatively, add the parentheses to those section headings
that

are commands and are currently missing parentheses.

10\. Page 16, Picture 5

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This picture includes several commands that do not exist in the rest of
the

document, such as \"ReportOnMove\" and \"Reset\". Remove these commands
from

the picture or replace them with commands that exist.

11\. Page 17, Picture 7

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This picture includes the command \"Put\", which does not exist.  Remove
this

command from the picture or replace it with a command that exists.

12\. Page 18, Picture 8

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This picture includes the command \"Put\", which does not exist.  Remove
this

command from the picture or replace it with a command that exists.

13\. Page 18, Picture 9

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This picture includes the commands \"Put\" and \"EndReport\", which do
not

exist.  Remove these commands from the picture or replace them with

commands that exist. In addition, it would be clearer if

\"OnMoveReportE(argname)\" were changed to \"OnMoveReportE(..)\".

14\. Page 19, Picture 10

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

In this picture, change \"StartSession(argname)\" to \"StartSession()\"
and

change \"EndSession(argname)\" to \"EndSession()\". StartSession and

EndSession do not take arguments.

15\. Page 29, Picture 19

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The PtMeasPars box is missing the following entries, which should be
there.

Approach, MinApproach, MaxApproach

Retract, MinRetract, MaxRetract

Search, MinSearch, MaxSearch

Since this box also appears on page 24 in Picture 13, any changes

should also appear there.

16\. Pages 31 and 32, Section 6.1.4

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The use of a production language to describe the syntax of I++ DME

commands (as has been done) is a very good idea, since production

languages allow one to write complete, clear, and unambiguous syntax

rules. This section, however, has the following problems in the way it

uses the production language.

Also from Rene Keller

A. The meaning of the symbols of the production language is not

   explained.

B. The use of curly braces is inconsistent. In the definitions of

   all terms except Number, it evidently means \"zero to many instances
of\".

   In the definition of Number, it seems to mean \"zero or one instance

   of\".

C. The wrong type of quotation mark is used in 24 places

   (not enumerated here).

Also from Rene Keller

D. The upper limit for Tag is given incorrectly as 99999. It should

   be 09999.

E. It is not made clear that a Tag must have exactly 5 characters.

F. It is not made clear that an UnsInt must have exactly 4 characters.

Also from Rene Keller

G. Enum is referenced but not defined.

H. The appearance of a space in quotes is very hard to see and is

   confusing.

I. The appearance of a quote in quotes is even harder to see and more

   confusing.

Also from Rene Keller

J. With the given definition of Number (if I understand it), some

   numbers which should be allowed, such as .3, are illegal (because

   the current definition requires at least one digit before the

   decimal point).

K. The limitation of 16 digits in a Number, which was in all previous

   versions of the spec, has disappeared. This limitation should be

   retained because it makes it easier to build interoperable systems.

L. The limitation of 255 characters in a String, which was in all
previous

   versions of the spec, has disappeared. This limitation should be

   retained because it makes it easier to build interoperable systems.

M. The underscore character \"\_\" is allowed in names. It should not be

   allowed because it is never used.

N. Not all definitions are collected in the section (Command, for

   example, is missing).  For ease of use by implementers, all

   definitions should be in this section.  Important definitions like

   Command can be repeated elsewhere.

O. The curly brackets in the definition of Number are unbalanced. There

   are 6 left curly brackets, but only 5 right curly brackets.

Also from Rene Keller

P. The term Arg is used but not defined, while Argument is defined but

   not used. Presumably they are intended to be forms of the same term.

Q. The curly brackets in the definition of ArgList are unbalanced. There

   are 5 left curly brackets, but only 4 right curly brackets.

R. ETag should be allowed as a method argument, since it is needed by

   StopDaemon, but it is currently not provided.

S. BasicName should be allowed as a method argument, since it is needed

   by GetCsyTransformation, SetCoordSystem, and SetCsyTransformation,

   but it is currently not provided.

The following version of section 6.1.4 is suggested as a replacement

for what is currently there. The production language used is very

similar to EBNF, but not identical. The production language used in

the suggested replacement sticks fairly closely to what is currently

there.

The only substantive difference between the replacement and what is

currently there is that the replacement allows numbers with no

digit before the decimal point (such as .3).

(START OF REPLACEMENT TEXT)

6.1.4 Definition of Syntax

This section defines the entire syntax of well-formed I++ DME commands

and responses, up to the \<CR\> \<LF\> line terminator. The syntax is
defined

using a production language. The production language is described in

section 6.1.4.1, and the syntax in section 6.1.4.2.

6.1.4.1 Production Language

Each statement in the production language is a single line of the form

  term  :==  definition

This means that any sequence of characters that matches the definition

can be considered to be an instance of the term.

For example,  Num  :==  \"0\"..\"9\"   is a statement that means a Num

is defined to be any of the characters from zero to nine.

The following special symbols are used in the production language.

\"\"  Any single character between double quotes means that literal

    single character. For example \"X\" means X (ASCII 88).

..  means in the range. For example, \"0\"..\"9\" means a single digit

    between zero and nine (including 0 and 9).

 \|  means \"or\"

()  A set of left and right parentheses means exactly one of whatever

    is enclosed. For example, (A \| B) means A or B. If a left or right

    parenthesis is surrounded by double quotes, i.e. \"(\" or \")\", it

    loses its special meaning and is just a single character.

\[\]  A set of square brackets means zero or one of whatever is
enclosed.

    For example, \[\"+\" \| \"-\"\] means a plus sign, a minus sign, or
no

    sign at all.

{}  A set of curly brackets means zero to many of whatever is enclosed.

    For example, {Num} means zero to many digits.

Anything on the right side of a statement that is not a special symbol

must be either a term already defined or a single character enclosed

by double quotes. Spaces inside a line have no significance other than

to separate terms.

6.1.4.2 Syntax

The syntax described here is complete, except that actual allowed values
of

Name and ArgList are much more limited than given here. Only names of

actual Commands may be used, and for each Command, only certain
arguments

are valid. The allowed names and arguments are described in Sections 6,
11,

and 12.

In four cases below, additional limitations are placed on allowed

syntax using natural language.

The definition of Number is necessarily messy-looking because the

following three conditions (among others) must apply:

a\. There must be at least one digit somewhere in the number.

b\. It is OK if there are no digits before the decimal point.

c\. It is OK if there are no digits after the decimal point.

In natural language, the definition of a number means: An optional sign

followed by one or more digits (optionally with a decimal point before
the

digits, between two digits, or after the last digit) followed optionally
by

an exponent. An exponent is an upper case E followed by an optional
sign,

followed by one, two, or three digits.

The definition of ErrorResponse is given on two lines because it will
not

fit on one line.

The definition implements the following rules regarding optional spaces.

Any number of optional spaces may appear (1) before or after a comma,
(2)

before or after a left parenthesis (3) before a right parenthesis.

Optional spaces may appear nowhere else. Note that a single non-optional

space is required in several places.

s :== \" \"

I.e. a single space (ASCII 32)

q :== \"\"\"

I.e. a double-quote character (ASCII 34)

Char :== s \| \"!\" \| \"#\" \| .. \| \"\~\"

I.e. ASCII character codes from space (ASCII 32) to \~ (ASCII 126),

excluding the double quote character (ASCII 34).

String :== q Char {Char} q

except that the number of characters between the quotes shall not exceed
255.

Alp :== \"A\" .. \"Z\" \| \"a\" .. \"z\"

I.e. any upper case letter (ASCII 65 to 90) or lower case letter

(ASCII 97 to 122)

Num :== \"0\" .. \"9\"

I.e. any digit (ASCII 48 to 57).

BasicName :== Alp {Alp \| Num}

Name :== BasicName { \".\" BasicName}

UnsInt :== Num Num Num Num

Tag :== \"0\" UnsInt

except that 00000 is not allowed.

ETag0 :== \"E\" \"0\" \"0\" \"0\" \"0\"

ETag :== \"E\" UnsInt

except that E0000 (which is ETag0) is not an ETag.

Exponent :== \"E\"\[\"+\"\|\"-\"\]Num\[Num\[Num\]\]

Number :== \[\"+\"\|\"-\"\]( (Num{Num}\[\".\"\]{Num}) \| (\".\"Num{Num})
)\[Exponent\]

except that the total number of digits shall not exceed 16.

SCommaS := {s} \",\" {s}

SLeftParenS := {s} \"(\" {s}

SRightParen := {s} \")\"

PropertyArgList :== {Number {SCommaS Number}}

Note that this may possibly be no characters at all.

Property :== Name SLeftParenS PropertyArgList SRightParen

Argument :== String \| Number \| Property \| ETag \| BasicName

MethodArgList :== {Argument {SCommaS Argument}}

Note that this may possibly be no characters at all.

Method :== BasicName SLeftParenS MethodArgList SRightParen

Command :== (Tag \| ETag) s Method

AckResponse :== (Tag \| ETag) s \"&\"

DoneResponse :== (Tag \| ETag) s \"%\"

NumData :== Number {SCommaS Number}

PropData :== String SCommaS String

PropertyList :== Property {SCommaS Property}

DataData :== NumData \| PropData \| Method \| PropertyList

DataResponse :== (Tag \| ETag) s \"#\" s DataData

F1 :== Num

F2 :== UnsInt

F3 :== String

Text :== String

ErrorResponse :== (Tag \| ETag) s \"!\" s \"E\" \"r\" \"r\" \"o\" \"r\"

         SLeftParenS F1 SCommaS F2 SCommaS F3 SCommaS Text SRightParen

Response :== AckResponse \| DoneResponse \| DataResponse \|
ErrorResponse

(END OF REPLACEMENT TEXT for section 6.1.4)

Also make the following changes to syntax definitions in other sections.

Page 34, Section 6.2.2.1

Change:   Command   :== Tag \| Etag \" \" Method

to:       Command   :== (Tag \| ETag) s Method

Page 65, Section 8.1

Change:   F1 :== UnsInt

to:       F1 :== Num

Page 65, Section 8.1

Change: ErrorResponse :== \...

to:     ErrorResponse :== (Tag \| ETag) s \"!\" s \"E\" \"r\" \"r\"
\"o\" \"r\"

           SLeftParenS F1 SCommaS F2 SCommaS F3 SCommaS Text SRightParen

Swen Haubold

17\. Page 38, Section 6.3.1 - preservation of state

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This section says: \"The following states of the server are preserved
upon

connection of the next client: Active tool, Active coordinate system\"

The following questions / problems came up:

1\) Are these states also preserved after shutdown of the server?

2\) Does the coordinate system make sense?

3\) Responsibility of the client for manual tool changes, after the
machine

   was powered off

4\) Different GUIs for the user.

1 Preservation of states

The specification does not specify the handling of the states after
power

up the system. This has also an impact on 3.

2 Coordinate system preservation

We have some concerns that the preservation of the coordinate system
makes

sense between the different sessions. In a client / server model there
is

no guarantee that the next client is the same application as the
previous

client, therefore normally the client can assume nothing.

3 Manual tool changes

After power off the system and the machine, the user has the possibility
to

change a tool system manually. Therefore after power up, the server
cannot

guarantee which tool is mounted (except for some special cases). Who is

responsible for the necessary user interaction to set / confirm the
active

tool?

4 Different GUIs

The client and the I++ server provide a GUI for different reasons. Also
the

\"normal\" user must work with the server GUI for probe qualification
and

some other tasks. Based on our discussion the user can get confused,
where

to find the correct menu / dialogue. This can also cause problems if for

example the confirmation of the active tool is done in the server GUI.
In

this case the user is never sure, which application must be used in
which

case?

Michel Penlae

18\. Page 38, Sec. 6.3.1.1, first paragraph - StartSession should clear
errors

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

StartSession() should clear all errors, in such a way that any

error condition left at time the front end (or another application)

closes the session / get disconnected does not prevent the
StartSession()

command execution.

Right now following sequence as recorded with current NIST I++ server :

1 StartSession() -\> OK.

2 EndSession() -\> OK

3 some garbage sent -\> ERROR

4 StartSession() -\> ERROR, must clear first. (StartSession then NOT
executed)

5 ClearAllErrors() -\> OK \[Can't be: cannot send a command before

  StartSession() !!! \]

6 StartSession() -\> OK ..

\-\-\-\-\-- We have a problem with that sequence in 3 and/or 4 and/or 5.

Suggested behavior:

a\) point 3 : Garbage ignored.

b\) No error reported at StartSession(), like if an implicit

ClearAllErrors() had been performed.

19\. Page 38, Section 6.3.1.1, first paragraph

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The sentence \"The server can be sure that the client will invoke

StartSession() only once during a session.\" is not helpful because the

server cannot be sure of this (or anything else about the client).
Remove

this sentence and replace it with: \"The client should not send a

StartSession command while a session is in progress. The server must
send

a \"Bad context\" error response if the client sends a StartSession

command while a session is in progress.\".

Also, under Errors, delete \"None\" and replace it with \"0508: Bad
context\".

As noted elsewhere, \"Bad context\" might be \"Protocol error\" instead.

20\. Page 39 and Page 41 - Regarding what happens after AbortE

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

On page 39 at the bottom of the page, it says that if any command other

than ClearAllErrors is received after AbortE, the server must send

an error response using error 0008 \"Protocol Error\".

First, there is no such error listed in Section 8.2, so it should be

added to Section 8.2.

Second, on page 41 in the example of what happens when a command other
than

ClearAllErrors is received after AbortE, errors 0511 and 0514 are sent,

but not error 0008. Change the example on page 41 to do what page 39

says should be done.

21\. Page 40, Section 6.3.1.6 - GetErrorInfo Response

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The GetErrorInfo command is supposed to return \"strings\". It is not
clear

whether this means to make a single response with several strings

(presumably separated by commas) or to make one or more responses,

each with a single string in it. The spec should state clearly what is

intended.

22\. Page 40, Section 6.3.17 - Errors of ClearAllErrors

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The ClearAllErrors method is not provided with any errors. It is likely

that some errors will be impossible to clear during a session, so some

method of reporting that the ClearAllErrors method was unsuccessful is

needed. Using error message 1000 \"Machine in error state\" might be

appropriate. Alternatively, a new error message \"Unable to clear

all errors\" might be defined.

23\. Page 42, Section 6.3.1.9 - GetProp Arguments

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The spec is not clear about what should be allowed as arguments.  Is it

intended that only primitive types (string, bool, number) can be
obtained?

If this is the intent, some combinations of arguments would be illegal.
For

example, GetProp(Tool.PtMeasPar()) would be illegal since the value of

PtMeasPar is an object, not a primitive type. If this is not the intent,

how should data be returned?

The spec is also not clear about whether CanChangeSpeed and
CanChangeAccel

are allowable keywords. These are included on pages 22, 26 and 71 for

GoToPars but are not included for PtMeasPars. None of the examples

uses either of them.

The spec is not clear whether properties of \"param\" objects defined on

pages 24, 29, 96, and 97 are intended to be directly accessible using

GetProp. These properties are not mentioned in section 6 and are not

included in any examples. If properties of param objects are intended to
be

directly accessible, they would presumably be accessed using a command
like

GetProp(Tool.PtMeasPars.Approach.Max()). Also, if this were the case,

would it be understood that a command like
GetProp(Tool.PtMeasPars.Approach())

is valid and means the same thing as
GetProp(Tool.PtMeasPars.Approach.Value())?

To make all this clear, delete the three lines ending with \"or other

methods that return properties.\" and replace them with a complete list

of all allowed arguments.

24\. Page 42, Section 6.3.1.9 - GetProp data

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

If a GetProp command has two or more properties as arguments, how is the

data to be returned? Is it all in one message, or is it returned in

several messages with one property value per message? If it is returned

in one message, what is the format?

25\. Page 42, Section 6.3.1.11 - SetProp Arguments

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The same problem arises with SetProp arguments as with GetProp
arguments,

as described immediately above. Fix it the same way.

26\. Page 42, Section 6.3.1.11 - SetProp Effect

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

What happens if a parameter value is commanded to be set out of range?

A statement like that on page 59 (but less ambiguous) should be included
in

this section as follows:

  For every property that has a numerical value and can be set with
SetProp,

  there are fixed maximum and minimum values. If a SetProp command is
given

  that attempts to set a value greater than the maximum allowed value,
the

  value will be set to the maximum.  If a SetProp command is given that

  attempts to set a value less than the minimum allowed value, the value
will

  be set to the minimum. The maximum and minimum allowed values of a

  property may be obtained using a GetProp command in which \"Max\" or
\"Min\"

  precedes the property name. For example, if the property is
xxx.yyy.Speed,

  GetProp(xxx.yyy.MinSpeed()) will return the minimum speed.

27\. Page 42, Section 6.3.1.11 - SetProp Return Value

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It is not clear what data SetProp should return. The spec says \"The
format

is defined by the method enumerated.\" This is not very clear, but seems

to say that data should be returned, and it should be returned in the

same format as in the command, so that, for example, the data response

to the command  SetProp(Tool.PtMeasPar.Speed(100)) would be:

Tool.PtMeasPar.Speed(100).

Should the returned value be the value in the command, or should it

be the value actually set (which might differ from the value in the

command)?

The example on page 63 does not show any returned data at all. This is

another possibility, but then the client will have to call GetProp to

find out what value was actually set.

28\. Page 42 and 43, Sections 6.3.1.12 and 6.3.1.13 - EnumProp and
EnumAllProp

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The descriptions of EnumProp and EnumAllProp are unclear. The difference

between the the two is also unclear. The meaning of these commands
should

be explained better in the spec.

One possible interpretation is that EnumProp returns the name of the
type

of a property, while EnumAllProp returns the names and types of the

immediate children of a property.  Under this interpretation, if the

command, for example, is EnumProp(Tool.GoToPar()), there is one response

message with data as follows:

\"GoToPar\", \"Property\"

If the command is EnumAllProp(Tool.GoToPar()), there are six response

messages, with data as follows:

\"MinSpeed\", \"Number\"

\"Speed\", \"Number\"

\"MaxSpeed\", \"Number\"

\"MinAccel\", \"Number\"

\"Accel\", \"Number\"

\"MaxAccel\", \"Number\"

If the commands behave as described above, it is possible to traverse a

property tree completely (from the root) by giving a number of EnumProp
and

EnumAllProp commands.

Is this the correct interpretation of these commands?

In addition, Section 7.7 on page 63 should have examples of both of
these

commands.  Currently, Section 7.7 has an example of EnumProp but no
example

of EnumAllProp. Judging from the responses, the command in the example

should have been EnumAllProp, not EnumProp.

29\. Page 42 and 43, Sections 6.3.1.12 and 6.3.1.13 - EnumProp and
EnumAllProp

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The existence of these methods seems pointless because the properties of

objects used in the interface are fixed, and the client knows what they

are. If variable properties were allowed in the server, with semantics

unknown to the client, these methods would be useless because all the

return values reveal is the name and type of the property; the client
would

have no idea what they mean.

Swen Haubold

30\. Pages 42,46, Sec 6.3.1.9, 6.3.1.10, 6.3.2.11 - GetProp/GetPropE/Get
similar

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The chapter 6.3.1.9 GetProp describes the command as follows:

\'The client uses this method to query properties of the system.\'

The chapter 6.3.1.10 GetPropE states:

\'The client uses this method to query the position of the active tool.

 GetPropE is handled with a high priority. See GetProp.\'

At last but not least the description of 6.3.2.11 Get:

\'The client uses this method to query the position of the active tool.

 Also temperature and calibrated tool properties can be requested.

 \...

 Also temperatures and other dynamic properties of the system can be

 requested.\'

Based on this description there is not much difference between the three

commands. Later on in the specification (6.3.3.5 X ff. 6.3.8 f.) there
is

the restriction that the position of the active tool can be only
obtained

by the Get and OnMoveReportE command. Also the term \"dynamic\" system

properties provides a large field for speculations.

Especially the property handling in general is not clearly defined.
Based

on the description this is limited to a number of pre-defined
properties,

based on the object model this is really extended up to every known

property.

Please confirm also with the next chapter.

Swen Haubold

31\. Page 43, Section 6.3.1.13 - EnumAllProp

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

For the EnumAllProp command no example is provided, therefore the output
of

this command is not clear. There is a link within the chapter to an
example

7.7 but this example only covers the EnumProp functionality. From my
point

of view the report format of the \"immediate children\" must be
something

like:

GoToPar.Speed(value)

GoToPar.Accel(value)

32\. Page 44, Section 6.3.2.1 - Home

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

No description is provided of what the Home command does, except saying

that Home means home, which is not adequate. Add a description of what

motion may occur when Home is executed. The client will need to know
this

in order to determine when it is safe to give a Home command. Suggested

text follows. If the text is not correct, write something similar that

is correct.

  When the home command is executed, the server will move the machine

  to its home position. The home position for a given machine is

  specific to the machine and is implementation dependent. The home

  position for a given machine is fixed. Any type of in-range axis

  motion may occur during execution of Home. The only requirement is

  that the final position be the home position.

 

It would be helpful if the above text can be changed to include
limitations

on axis motion (such as requiring that the Z axis be fully retracted

first). Without limitations, behavior will vary from system to system so

that in moving an inspection program from one machine another, the user
may

have to clear out the entire work volume before executing Home or risk

a collision.

Swen Haubold

33\. Page 44, Section 6.3.2.2 - IsHomed

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

In the remark section of the IsHomed command the specification mentions

that the value of a single axis can be obtained via the GetProp()

command. In this context the internal axis class must be provided as

mentioned in the object model and also a non-existing method for

IsHomed. This is also a typical example where the functionality of the

system is described in some subordinate clause.

34\. Page 44, Section 6.3.2.4 - Implicit DisableUser

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The remark at the end of section 6.3.2.4 says \"The server calls this
method

implicitly whenever the client calls a method that physically moves the

machine.\" Does this mean the client must call EnableUser again to
enable

the user, or if the user was enabled before the motion, is the user

enabled again automatically after the commanded motion is completed? The

text should make this clear.

35\. Page 45, Section 6.3.2.6 - OnPtMeasReport

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The spec forbids having no arguments to OnPtMeasReport. With this rule,
it

is not possible to command that nothing should be reported on PtMeas. It

should be possible to command that nothing be reported. The simplest way
to

do this is to get rid of the rule (i.e., allow OnPtMeasReport with no

arguments).

Swen Haubold

36\. Page 45, Section 6.3.2.7 - OnMoveReportE

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

In OnMoveReportE there is the statement that if the enumeration list is

empty no report should be sent. Unfortunately the handling of the daemon
is

not clear. Does a daemon in this case have to be created or not. This
has

some impact on the 6.3.1.3 StopDaemon command.

Even there is the statement the report frequency must not be higher than
10

Hz. Based on my German background I\'m currently not sure if this means

\'must not be higher\' or if this means the server has only to guarantee
a

report frequency of at most 10 Hz. This type of translation is very
often

faulty in translations from German to English.

37\. Page 45, Section 6.3.2.7 - OnMoveReportE

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

What is the intended effect of multiple instances of this command?

The simplest and most reasonable intent would be that if one instance of

the command follows another, the later one completely replaces the
first.

If this is the intent, then presumably the command OnMoveReportE() shuts

off all OnMove reports. This is fine, but then what is left for
StopDaemon

to do? Also, if this is the intent, OnMoveReportE commands with only
Time

and/or Dis arguments have no effect (no way is provided to report time
or

distance data) and should be made illegal.

Another possible intent is that each OnMoveReportE command has no effect
on

existing OnMoveReportE daemons, but just creates a new, independent one.

If this is the case, why does the spec say \"If the enumeration is
empty,

no reports are sent\". Does that mean it is possible to create a daemon

that does nothing? If this is the intended effect, then StopDaemon

(or StopAllDaemons) must be called to stop the effects of each

OnMoveReportE command.

A third possible intent is that later commands modify earlier ones

For example, suppose the following four commands are given:

E0001 OnMoveReportE(Time(0.5), Dis(0.2), X())

00002 GoTo(X(20), Z(76))

E0003 OnMoveReportE(Y())

00004 GoTo(X(-20))

In this case, only the X position is reported during first GoTo, while

both the X position and the Y position are reported during the second
GoTo.

If this is the intent, specific rules for how later commands modify

earlier ones will be required.

Whatever the intent is, it should be clearly stated.

38\. Page 45, Section 6.3.2.7 - Data from OnMoveReportE

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The text on page 45 says no data is returned from OnMoveReportE.  The

example on page 37 shows data being returned with the tag of an

OnMoveReportE command. These two facts are inconsistent. Since data

resulting from the user moving the machine could belong to no other
command

than an OnMoveReportE command, it seems most reasonable to report such
data

using an OnMoveReportE tag.

The text on page 47 in section 6.3.2.12 says GoTo does not return

data. There is no example in the document of data being returned as a

result of the motion caused by executing a GoTo. If there were an
example,

the returned data would presumably use the tag of either an
OnMoveReportE

command or a GoTo command. It would be better to use the tag of the

OnMoveReportE so that the command tag would be the same whether the user

caused the move or whether executing GoTo caused the move.  There is
also

no example of data being returned while a PtMeas is in progress (before
or

after a touch point is recorded). Presumably such data would also be

reported using the tag of an OnMoveReportE command.

The text on page 45 should be changed to indicate that OnMoveReportE

returns data and that whenever position data other than touch point

data is returned, it should use the tag of the most recent OnMoveReportE

command.

It would be helpful to put a sentence in section 6.3.2.7 pointing out
that

OnMoveReportE differs from OnPtMeasReport and OnScanReport in that

OnMoveReportE returns data but OnPtMeasReport and OnScanReport do not

return data.

39\. Page 45, Section 6.3.2.7 - OnMoveReportE

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This is a minor editorial comment.

The sentence \"The report frequency must not be higher than 10 Hz.\"

introduces new undefined terms (frequency and Hz) that are not needed
and

appear nowhere else in the document. It would be better to replace the

sentence with \"The value of Time must not be less than 0.1.\".

40\. Page 47, Section 6.3.2.11, second line of page

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Change \"Tool().A()\" to \"Tool.A()\". The \"Tool().A()\" syntax is
illegal

and occurs nowhere else in the document.

Swen Haubold

41\. Page 47, Section 6.3.2.12 - GoTo

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The GoTo command has the restriction that no movement is done if an out
of

limit condition for the target position occurs (implicitly: 6.3.3.9 X

ff.). In the case that the server already handles the out of limits

conditions how is the error handling affected? Based on the
specification

this will generate an error 2500 (severity class 3) which is not handled
in

example 6.3.2.1.

\[Also Rene Keller\]

Even the synchronised handling between tool axes and machine axes as

defined in the command cannot be guaranteed for many actual probe
systems,

because this requires the possibility to set the acceleration and speed
of

probe head movement and a tight synchronisation of the axes of the probe

head and the machine itself. Based on the current implementation of the

ABCGoToPar and ABCPtMeasPar this is also clear for the I++ working
group,

therefore I do not understand the requirement for the GoTo command. Even

the methods for the 6.3.9 A, B, and C axes methods mention that the tool

alignment should be only done by AlignTool to guarantee the

interoperability between different implementations.

42\. Page 47, Section 6.3.2.12, description of GoTo parameters

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Currently, GoTo commands are not required to have all of X, Y, and Z.

For example, \"GoTo(X(3))\" is legal.

If it is intended that all of X(), Y(), and Z(), must be present,

change the description of the parameters to: \"The argument list is

an enumeration of the three methods X(), Y(), and Z().\" Note that

since it is an enumeration, they may occur in any order. If it is

intended that they be in order, add the phrase \"in that order\".

If the current situation is what is intended, add a description of

what values the missing methods should have. Presumably the missing

coordinates are intended not to change. If this is correct, add: \"If

any of X(), Y(), or Z() is not included as an argument, its value

after the GoTo is executed must be the same as its value just before

the GoTo was executed.\"

43\. Page 47, Section 6.3.2.13, title of section

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The heading of this section is \"PtMeas(..), PtMeasIJK(..)\"

The heading makes it appear that PtMeasIJK is a valid command, but there

is no description of it as a separate command, there are no examples

of it in the document, and there is no need for it (since it is obvious

when IJK is used as an argument to PtMeas). It would be better to delete

\", PtMeasIJK(..)\" from the section heading.

44\. Page 47, Section 6.3.2.13, description of PtMeas parameters

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Currently, PtMeas commands are not required to have all of X, Y, and Z.

For example, \"PtMeas(X(3))\" is legal.

If it is intended that all of X(), Y(), and Z(), must be present, change

the description of the parameters to: \"The argument list is an
enumeration

of the three methods X(), Y(), and Z().\" Note that since it is an

enumeration, they may occur in any order. If it is intended that they be
in

order, add the phrase \"in that order\".

If the current situation is what is intended, add a description of

what values the missing methods should have. It is not obvious what

values should be used for the missing methods. There are several

possibilities, including:

a\. Use the value at the position just before the PtMeas is executed.

b\. Use the last explicit nominal value given in a previous PtMeas

   command.

c\. Use the last actual value found by executing a PtMeas command.

Also if the current situation is what is intended, as currently stated,
a

PtMeas command with only an IJK parameter is legal. If this is not
intended

to be legal, say so explicitly. If it is intended to be legal, describe
how

to assign values to X, Y, and Z.

45\. Page 47 and 48, Section 6.3.2.13 - description of PtMeas

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This description is generally good, but still needs improvements as

follows.

a\. In the second line of the section and in the fifth line on page

48, the term \"clearance\" is used, which is not defined. In both

cases, \"clearance\" should be changed to \"approach\" (which is
defined).

b\. The second bullet on page 48 makes it sound like the nominal
position is

being changed, which is not what is intended. Change the first two lines

of the second bullet to:

  A new position is found by moving in the I,J,K direction from the

  X,Y,Z nominal position by the following values:

c\. The fourth bullet on page 48 also makes it sound like the nominal

position is being changed, which is not what is intended. Change the
fourth

bullet to:

  Another new position is found by moving from the X,Y,Z nominal
position

  opposite the I,J,K direction by the value of Tool.Search(). This

  position is called the end of search position.

d\. In the fifth bullet on page 48, change \"to\" to \"towards\".

e\. In the top diagram on page 48, there is an arrow labeled
\"Search\[Part\]\".

There is no such thing anywhere else in the document. Delete the arrow
and

label from the figure.

f\. The second bullet on page 48 says the approach point is supposed to

be shifted by Tool.Radius() (and another distance) but Tool.Radius()
does

not appear on the figure. Add Tool.Radius() to the figure in the

appropriate place.

g\. In the figure, Approach\[Tool\] and Approach\[Part\] are added
together to

determine the approach point, while in the second bullet, it says

Tool.Approach is used as a minimum for warning (which seems to imply it
is

not added in). If the figure is correct, change the text. If the text is

correct, fix the figure.

Swen Haubold

46\. Page 49, Section 6.3.2.14 - movement with RefTool or BaseTool

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This section covers 4 standard tools: BaseTool, RefTool, NoTool, and

UnDefTool. Based on the specification it is not clear if the RefTool and

BaseTool can be used for movement.

Michel Penlae

47\. Page 49, Section 6.3.2.14 - Naming convention needed

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

There is a need to group somehow Tools who pertain to an assembly, like
a

star tip.  This could be achieved so far by a kind of convention that a

tool name could possibly be in the XXX_YYY form, where XXXX is the name
of

the assembly and YYYY the real identifier of the tip. All this to allow
the

front end to present the tools in a logical way to the operator. 
Another

(preferred) way would be to have the tool have a/some properties to
reflect

the grouping, like a cluster name or similar properties.

48\. Page 49, Section 6.3.2.16 - FindTool returned data

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Section 6.3.2.16 says that data sent in response to a FindTool command

should be \"FoundTool\", but the example on page 63 does not show any

returned data. Is data returned or not? If so, what is the format of

the data?

49\. Page 49, Section 6.3.2.16 - effect of FindTool

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

There are two problems with the effect of FindTool.

A. Is FindTool(\"UnDefTool\") a legal command? If so, it should be
possible

to get the properties of UnDefTool using GetProp(FoundTool\...). But

UnDefTool, presumably, has no properties so GetProp(FoundTool\...) will

then return an error. It would seem best to make FindTool(\"UnDefTool\")

illegal.

B. Suppose FindTool is called successfully so that there is a FoundTool,

and then FindTool is called unsuccessfully. What happens to FoundTool?

Does it stay unchanged, or does it become NoTool, or does something

else happen?

Note that the comment at the end of Section 6.3.2.17 says that FoundTool

can be a pointer to NoTool.

50\. Page 50, Section 6.3.2.17

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It is not clear what should happen if FoundTool() is used and there

was no previous call to FindTool(). Two possibilities are:

a\. The server should return an error.

b\. The server should use NoTool.

Add a sentence describing how the server should behave in this case.

51\. Page 50, Section 6.3.2.17

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The errors section has not been completed. Either list errors or

write \"None.\".

Michel Penlae

52\. Page 50, Section 6.3.2.20

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

AlignTool: This preferred command is based on the assumption

that, for a given tool, instead of indicating A and B (and possibly C),

one can provide the IJK to align the tip stem to. The one to one

relationship is mostly OK for a PH10 style probe head (except for A=0),

since the A (vertical in case of a bridge machine) is from 0 to

something (90105) degree, and NOT -90 to +90. If this A angle can go

from -90 to +90 , then there are 2 symmetrical set of (A,B) that can

fulfill some IJK. This can give significant trouble when probe is offset

to the ram, because the 2 symmetrical ram position corresponding to the

IJK can be some 100mm+ apart. (even in a PH10, if A is 0, the IJK=

(0,0,1), vertical stylus, is corresponding to A=0 and B= any angle).

53\. Page 51, Section 6.3.2.20 - AlignTool data

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The data in a response to AlignTool is supposed to be \"vectors\". It is

not clear how the data is supposed to formatted. If there are two
vectors,

there are at least two reasonable formats: (i1, ji, ki, i2, j2, k2)

or ((i1, ji, ki), (i2, j2, k2)). Which is intended?

54\. Page 51, Section 6.3.2.21

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The errors section has not been completed. Either list errors or

write \"None.\".

55\. Page 51, Section 6.3.2.22

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The errors section has not been completed. Either list errors or

write \"None.\".

56\. Page 51, Section 6.3.2.23 - EnumTools data

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The text says the names of all values should be returned, but the
example

omits BaseTool, RefTool, NoTool, and UnDefTool. The text should state

explicitly whether these are to be included. If they are, the example

should be changed to include them. The example includes a tool named

\"ReferenceProbe\". This is confusing, since there is already a
\"RefTool\".

The example would be clearer if \"ReferenceProbe\" were deleted.

(by request from several implementers)

57\. Page 52, Section 6.3.2 - calibrated tool data

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

A method is needed of getting tool calibration data. The specific items

of data are:

1\. the ball radius

2\. the tool offset (to the ball center?)

3\. the timestamp for when the calibration was done

4\. a measure of the quality of the calibration.

There are several ways this might be implemented. One straightforward

method would be to define a \"GetCaliProp\" command as in the following

proposed text. This uses the Tool() or FoundTool() method to identify

the tool for which calibration data is being requested. It may also

be possible to use GetProp rather than adding a new keyword.

(START OF PROPOSED TEXT)

6.3.2.24 GetCaliProp(..)

The client uses this method to query calibration data for a tool.

It returns the requested data for the tool.

    \> GetCaliProp(..)

Arguments  The argument list is an enumeration of one or more methods
from

           one of the following two sets of methods.

           Tool Set:  Tool.BallRadius()

                      Tool.Offset()

                      Tool.CaliTime()

                      Tool.CaliQuality()

           FoundTool Set: FoundTool.BallRadius()

                          FoundTool.Offset()

                          FoundTool.CaliTime()

                          FoundTool.CaliQuality()

           All of the items in the enumeration must be from the same set

           (i.e. items from the Tool Set and the FoundTool Set must not

           both be used in the same command).

Data       Data is returned in the following formats. Returned data must

           use the same methods as given in the command, but they are

           not required to be in the same order.

           Tool.BallRadius(..)       radius in millimeters

           Tool.Offset(..)           offset in millimeters

           Tool.CaliTime(..)         time in seconds since beginning of
2000

           Tool.CaliQuality(..)      average ball radius error in
millimeters

           FoundTool.BallRadius(..)  radius in millimeters

           FoundTool.Offset(..)      offset in millimeters

           FoundTool.CaliTime(..)    time in seconds since beginning of
2000

           FoundTool.CaliQuality(..) average ball radius error in
millimeters

          

Errors     1502: Tool not found (if FoundTool properties requested and

                                 there was no previous call to FindTool
or

                                 the most recent call to FindTool was

                                 unsuccessful)

           1503: Tool not defined (if the tool is UnDefTool)

           1504: Tool not calibrated (if the tool is not calibrated)

Remarks    NoTool and BaseTool are never calibrated. RefTool may or may

           not be calibrated.

          

(END OF PROPOSED TEXT)

There may be preferable measures of time and quality. If so, they should

be used instead of those in the proposed text. It is desirable that the

measures be single numbers to avoid the need for data type definitions
and

complicated parsers.

Swen Haubold

58\. Pages 54 and 55, Sections 6.3.3.3 and 6.3.3.4 -
\[Set/Get\]CsyTransformation

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The commands GetCsyTransformation and SetCsyTransformation already have
as

valid parameters the enumeration of \"JogDisplayCsy\", \"SensorCsy\",
and

\"JogMoveCsy\". These are part of the unscheduled enhancements as
described

in chapter 1.6.

59\. Page 56, Section 6.3.3.8

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The last sentence of the section says that IJK can be used only as an

argument of OnPtMeasReport(). However, IJK may be an argument to PtMeas
and

does not appear to be a valid argument to OnPtMeasReport(). According to

section 6.3.2.6 on page 45, the arguments to OnPtMeasReport are those of

Get.  According to section 6.3.2.11 on pages 46 and 47, IJK is not a
valid

argument to Get.

Change the last sentence of section 6.3.3.8 to \"This method can only

be invoked as an argument to PtMeas().\".

Marcel Lenherr

60\. Page 57, Section 6.3.3.12

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The text says an IJK vector must be expressed in terms of the machine

coordinate system. A more general solution is required. Change

\"machine coordinate system\" to \"selected/actual coordinate system\".

61\. Page 57, Section 6.3.3.13

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Change the line \"Data   R()\" to \"Data   R(r)\". Otherwise, no data is

returned.

62\. Page 57, Section 6.3.3

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Add definitions of Time(..) and Dis(..) methods as sections 6.3.3.14

and 6.3.3.15. These are used in OnMoveReportE and should be defined in

this section.

63\. Page 58, Section 6.3.4 - Installing Tools

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The document provides no method for either the client or the server

to define new tools. The document should at least discuss how it is

intended that tools be defined. In the NIST implementation, tools are

hard-coded in the C++ source code. This is clearly not a practical

solution for a real system.

The first sentence of page 58 says \"Each CMM implements one instance of

the ToolChanger class to install and change tools.\". However, no
provision

is made for installing tools (the word \"install\" appears nowhere else
in

the document). There is not even C++ support for the server to install a

tool. On page 92 there is a section of C++ code that includes a Tool.Add

method that appears to be intended to be used to install a tool, but
this

section has been commented out.

The server source code in Appendix A should provide methods for the
server

to install tools.

If it is decided that the client should not be able to install tools,
this

should be stated explicitly.

Swen Haubold

64\. Pages 58 and 59, Sections 6.3.6 and 6.3.7 - GoToPar and PtMeasPar

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The parameter block description of GoToPar and PtMeasPar covers

that every property is split in Min, Max, Act, and Def. Based on the

example 7.7 the parameter \"Speed\", \"Accel\", and \"Approach\" have no

immediate children. The object model describes the access of the Min and

Max values of the speed and acceleration properties as:

MinSpeed, MaxSpeed, MinAccel, and MaxAccel.

Which definition is the correct one? Based on the rest of the
specification

an access like:

GoToPar.Speed.Min and GoToPar.Speed.Max

would be correct.

The access to the \"Def\" is not covered, if I take the Speed as an
access

method of the actual property into account. Based on the description of

\'6.3.2.11 Get\' this property can be only accessed through this
function,

because this function is the only one which has the statement that the

properties accessible by this function cannot be changed directly.

65\. Page 59, Sections 6.3.6 and 6.3.7 - Act and Def

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The terms Act and Def appear on page 59. These terms are not defined

anywhere in the spec and do not appear on any other page of the spec.

Presumably, they mean Actual and Defined. No explanation is given in the

spec about which of these should be returned in response to a GetProp

command.

One guess about what \"Actual\" and \"Defined\" mean is:

1\. The Defined value is what you get as a result of giving a SetProp
command.

This value may not be what was in the SetProp command, but it is a fixed
value.

2a. For speed and acceleration, the Actual value is whatever it actually

is at the time it is recorded. That varies from instant to instant, so,

depending on when the value is recorded, the value returned as data in

response to a GetProp command will vary.

2b. For approach, search, and retract, the Actual value might be the
value

that was used during the last PtMeas, or it might just be the same as
the

Defined value.

Another guess about what \"Actual\" and \"Defined\" mean is:

1\. The Defined value is the value that was given in the last SetProp
command.

2\. The Actual value is the value that resulted from the last SetProp

command.

The best solution would be to delete both Act and Get from page 59.

66\. Pages 59, 29, and 95, Sections 6.3.6, 6.3.7, 5.9, and A.6.5 -
CanChange

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The model on page 29 and the header files on page 95 have CanChangeSpeed

and CanChangeAccel methods while sections sections 6.3.6 and 6.3.7 say

nothing at all regarding any kind of change. If there are CanChange

methods, they should appear somewhere in Section 6. If not, they should

be deleted elsewhere.

67\. Page 58, Section 6.3.5.1

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The errors section has not been completed. Either list errors or

write \"None.\".

68\. Page 58, Section 6.3.5.2

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The errors section has not been completed. Either list errors or

write \"None.\".

69\. Page 59, Section 6.3.6, last sentence

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The sentence \"If trying to set the actual value outside the defined
range,

the Max or Min value is used.\" is ambiguous (although the intent is
clear).

Delete that sentence and replace it with the following.

  If a command to set a GoToPar above the Max is received, the server

  must set the GoToPar to the Max. If a command to set a GoToPar

  below the Min is received, the server must set the GoToPar to the

  Min.

70\. Page 59, Section 6.3.7,  next-to-last paragraph, last sentence

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The sentence \"If trying to set the actual value outside the defined
range,

the Max or Min value is used.\" is ambiguous (although the intent is
clear).

Delete that sentence and replace it with the following.

  If a command to set a PtMeasPar above the Max is received, the server

  must set the PtMeasPar to the Max. If a command to set a PtMeasPar

  below the Min is received, the server must set the PtMeasPar to the

  Min.

71\. Page 65, Section 8.1, syntax definition of F1

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Field F1 is described as being one of the five digits 0, 1, 2, 3, or 9,

and in all the examples in the document, F1 consists of one digit.

Therefore, the field F1 should contain just one digit.

Change:   F1 :== UnsInt

to:       F1 :== Num

72\. Page 65, Section 8.1, syntax definition of ErrorResponse

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Assuming the proposed revision of Section 6.1.4 given above is used,

the definition of ErrorResponse given in Section 8.1 should be the

same as the one in Section 6.1.4.

Change: ErrorResponse :== \...

to:     ErrorResponse :== (Tag \| ETag) s \"!\" s \"E\" \"r\" \"r\"
\"o\" \"r\"

           SLeftParenS F1 SCommaS F2 SCommaS F3 SCommaS Text SRightParen

In the current definition of ErrorResponse, a double-quote that looks

like 66 is used where a double-quote that looks like 99 should appear

in eight places.

73\. Page 65 Section 8.1, description of Text

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

No description of Text is given. After the description of F2, add

the following.

 

  Text: The text string must be the text string shown in

  section 8.2 for the error number given in the F2 field.

74\. Page 65, Section 8.1 - example of error response

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The line \"0003 ! Error(F1,F2,F3,Text)\" is a strange mixture of an

example and a template. The \"0003\" is an (incorrect) example of a

Tag, while F1, F2, F3, and Text are templates.

Delete that line and at the end of the section insert the following.

  Here is an example of an ErrorReponse.

  00004 ! Error(2,0502,\"GoTo\",\"Incorrect parameters\")

  Other examples are shown in Sections 6.2.3.1 and 6.2.4.1.

Also Rene Keller

75\. Page 66, Section 8.2 - missing errors

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

According to Section 6.1.1 on page 31, there should be an error message

0007 with text \"Illegal character\".

According to Section 6.3.1.5 on page 39, there should be an error
message

0008 with text \"Protocol error\".

Therefore, add the following two entries to the table on page 66.

  2   0007   Illegal character

  2   0008   Protocol error

76\. Page 66, Section 8.1 - Error Severity and Text

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

There is no point in sending the error text and severity in an Error

message. Once you know the error code, the severity and text are known

because they are in the spec. The only effects of sending the text and

severity are negative: (i) the message is harder to parse (ii) parsing

takes longer (iii) it is possible to make a mistake by sending the

wrong severity or the wrong text (which makes life yet harder for the

response parser, since it then should check if the severity and text

are correct).

77\. Page 65 and 66, Section 8.2 - inappropriate error severities

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Many of the error severities given in the table are inappropriate.

The description of the meaning of the severity codes says that:

Severity code 1 should be assigned if this is only a warning. Presumably

this implies that the command can be carried out, but not exactly as

intended by the client.

Severity code 2 should be assigned if the client can repair the

error. Presumably this implies that the command cannot be carried out at

all, but the client can continue and may be able to do exactly what the

client intends to by giving some other command or by giving commands in

some other order.

Severity code 3 should be assigned if the server cannot continue and
user

interaction is needed.

Using these criteria, the following severities should be assigned
instead

of the ones currently listed. Some error messages are so unclear it is
not

evident what severity they should have.  These are discussed in the

next comment.

In general, any syntax or protocol error should have severity 2. The

server either cannot or must not execute the command in these cases,

but since the error is discoverable before the server takes any action,

it should always be possible for the client to continue.

The following commands that are not now severity 2 should be severity 2

for the reason just given. As mentioned earlier, \"parameter\" should be

changed to \"argument\" everywhere it appears in the error messages.

That change is made below.

0502 Incorrect arguments

0505 Argument not recognized

0507 Illegal command

0508 Bad context

0509 Bad argument

0510 Bad property

1002 Axis does not exist

1004 Number of angles not supported on current device

1007 Theta out of range

1008 Target position out of machine volume

2002 Type of probe does not allow this operation

Three commands that are now severity 2 seem that they should be severity
3

or 9, since they happen only if the server or machine is not working

correctly, so that user interaction (or a service call) is needed.

These are:

0511 Error processing method

1005 Error during home

2502 Axis position error

Error 0504 \"Argument out of range\" currently has severity 1, which is

just a warning. If the command is carried out, it is very likely that

its effect will not be what the client wants. It would seem better to

assign severity 2 to this error so the client can take action before

there are any unwanted effects.

78\. Page 65 and 66, Section 8.2 - obscure error messages

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

In two cases, it is not at all clear what an error message means and in

what circumstances the message should be used.  For the two cases listed

below the error message appears nowhere else in the document.

0000 Buffer full. It is not clear what buffer this is talking about.

     It is not clear why this is only a warning. If the full buffer

     is the one that is supposed to receive command messages, then

     it seems likely that part or all of one or more command messages

     already sent by the client ended up in the bit bucket, so the

     command cannot be carried out and the client will have to take

     action to recover. In this case, severity 2 would be appropriate,

     not severity 0 (the current severity).

0005 Suspend communication. Is this a notice that communication is about

     to be suspended by the server? Is it a request to the client to

     stop sending commands for a while? Either way, how will the client

     know when to resume?

79\. Page 66, Section 8.2 - handling of errors that occur before
execution

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The types of errors in an instance of a command that can be detected by
the

server before execution starts are described below. The handling of
these

cases needs to be improved by adding error messages and giving rules

describing when various error messages should be used. Rules are
proposed

here.

The spec does not state whether the server may or must send multiple
error

messages if it detects multiple errors in a single command (although the

examples in section 6.3.1.7 on page 41 show two errors returned for one

command). The spec should make an explicit statement about this. It

seems simplest and best if only one message is sent. That message should

report the first severity 2 error encountered using the most specific

applicable error message. If there are no severity 2 errors, the first

severity 0 or 1 error encountered should be reported. The following

sections of this comment are arranged in a suggested priority order, so

that the error that appears first in the text below is the one that
should

be reported, if there is a choice.  For example, if there is an illegal

character as one of the first five characters of a command message,

\"Illegal character\" rather than \"Illegal tag\" should be used. But if
the

tag is illegal and an illegal character appears in the argument list,
then

\"Illegal tag\" should be used.

Note that the server must be able to read all commands allowed by the
spec,

even if it cannot carry out all commands. The spec should require this

explicitly. Otherwise, the server may return \"Command not recognized\"

errors when it should be returning \"Command not supported\" errors,

masking the fact that the command is OK but the system has not
implemented

it.

A. First six characters

i\. If an illegal character is included in the first six characters,
error

   message 0007 \"Illegal character\" should be used.

ii\. If the tag is illegal because it is an illegal number or is already

   in use, error message 0001 \"Illegal tag\" should be used.

iii\. If the sixth character is not a space, error messages 0002 \"No
space

   at pos. 6\" should be used.

No change in error messages is needed for these three types of error,
but

these rules should be stated explicitly.

B. Command Name

The following rules should apply while parsing the command name

(which should not be attempted if there was an error in parsing the

first six characters). The command name starts with the character

at position 7 and ends with the last non-space character before

the left parenthesis that starts the argument list.

i\. If an illegal character is included in the command name, error
message

   0007 \"Illegal character\" should be used.

ii\. If the characters that should form a command name do not form the
name

   of any command defined by the spec, the error message should be
\"Command

   not recognized\" (analogous to \"Argument not recognized\" for
arguments).

   This error message exists with different text as 0507. The text
should

   be changed.

iii\. If the characters that should form a command name do form the name
of

   a command defined by the spec, but this server does not have the

   capability to carry out any instance of this command, the error
message

   should be \"Command not supported\" (analogous to \"Argument not

   supported\"). This error message exists with different text as 0501.

   The text should be changed.

C. Arguments

The following rules should apply while parsing the argument list of a

command (which should not be attempted if any of the earlier errors

has occurred). The argument list starts with the character after the

left parenthesis that marks the end of the command name. The argument

list ends with the newline and carriage return at the end of the

command message.

In the case of parsing the argument list, different parsing techniques
may

detect different errors, so some flexibility must be allowed among the

messages suggested below.

i\. If an illegal character is included in the argument list, error
message

   0007 \"Illegal character\" should be used.

ii\. If the characters in the argument list do not form a recognizable
list

   of command arguments that individually conform to the spec, and no

   other more specific error message is appropriate, error message 0502

   \"Incorrect arguments\" should be used. A better text for this
message

   would be \"Bad format argument list\".

iii\. If a set of characters that should form a name that might be an

   argument (or a component of an argument) do not form such a name,

   error message 0505 \"Argument not recognized\" should be used.

iv\. If:

   a. a command and its arguments have been recognized,

   b. some instances of the command can be executed by the server,

   c. there is an allowed argument type whose use in a command

      of the given type always makes the server unable to execute the

      command, and

   d. one of the arguments is of the bad type,

   then error message 0506 \"Argument not supported\" should be used.

v\. If a command argument has been recognized, the argument value is

   a number or holds a number, the number is required to be in some

   simple range, (i.e. min \< value \< max, where either \< could be
\<=),

   and the value is not in that range, error message 0504 \"Argument

   out of range\" should be used.

vi\. If a command argument is supposed to be a property and it is not

   a property allowed by the spec for that command, error message 0505

   \"Bad property\" should be used. (i.e. this is like an out-of-range

   condition for arguments that are property names).

vii\. If a command and its arguments have been recognized but the

   argument list does not satisfy constraints of the command, error

   message 0509 \"Bad Argument\" should be used.

D. Command as a Whole

i\. If the command name and arguments are OK, and the server can carry
it

   out when conditions are correct for executing it, but those
conditions

   do not currently exist, if a specific error message applies, it
should

   be used. If not, the error message for this should be 0508 \"Bad
command

   context\" or 0008 \"Protocol Error\". Error message 0508 currently
has

   different text. The text should be changed. It may be that 0508 and

   0008 are not both needed. Rules or suggestions should be given for
when

   to use 0508, 0008, or a more specific message. Here are examples.

   \-- If a PtMeas command is given when no tool is loaded, use

      2002 \"Type of probe does not allow this operation\", since the

      Tool() is NoTool, not 0008 or 0508.

   \-- If a GoTo command is given during a session before a Home command

      is given, use 0008 or 0508.

   \-- If a StopDaemon command is given with an argument that is a legal

      Tag and no Daemons are active, use 0513 \"Daemon does not exist\"

      rather than 0512 \"No daemons are active\" or 0008 or 0508.

ii\. If the command and arguments are OK and conditions are right for

   executing the command, and the server can execute some command
instances

   but not this one (for any reason), error message 0515 \"Command
instance

   not supported\" should be used. This is a new error message not
currently

   included in the document. This might be used, for example, if there

   is a fixed obstacle in the work volume of the machine and a GoTo
command

   is issued with the target point inside the obstacle.

Swen Haubold

80\. Page 67, Section 9.1

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\>From my point of view even the extension handling as described in
chapter 9

is complicated for the interoperability. In this case some parties may

provide additional functionality which can be used against competitors. 
In

this case the original goal of interoperability cannot be achieved.

81\. Page 69, Section 9.7 - move to section 1

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

This section is hidden in the middle of the document. It would be much

more appropriate to move it to be section 1.8, since section 1 contains

all the other information about organizations related to the spec.

82\. Page 71, Section 11.1.2 - wording

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The sentence starting \"To increase system performance \...\" is very

awkward. The following wording is suggested, which is intended to

have the same meaning.

  To increase system performance, already measured data may be

  transmitted from the server to the client while the execution of

  the scanning command is still in progress.

83\. Page 71, Section 11.1.2

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It would be useful to put a maximum on the number of measurement results

that can be returned in one string. The only current upper limit is

whatever fits inside the ceiling of 65536 characters in a message.

84\. Page 71, Section 11.1.2

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It is not clear what to do if a scan command is given before any

OnScanReport has been given. It might be a protocol error, or perhaps

by default only X, Y, and Z are reported, or perhaps something else

happens. The spec must state explictly how to deal with this.

85\. Page 71, Section 11.1.2

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The order in which scanning data items are to be returned is not

clear. It might be the order in which they are given in the last

OnScanReport, or it might be alphabetical order, or it might be some

other order. The spec must state explicitly how the order is determined.

86\. Page 72, Section 11.2.1 - Form

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The statement \"Form defines the maximum expected form deviation
calculated

by Gauss of the circle.\" is very vague. The term \"form deviation\"
should be

defined, and the formula by which it is calculated should be given.

87\. Page 72, Section 11.2.2 - StepW

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It would be clearer if the StepW argument had its name changed to

StepAngle, since it is an angle, not a distance. Also, it would be
helpful

to require either that StepW always be positive or that StepW always
have

the same sign as Delta.

88\. Page 73, Section 11.2.2, second paragraph

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It should be stated that a positive angle delta is counterclockwise as

viewed from the positive Z axis.

89\. Page 73, Section 11.2.3 - Form

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The statement \"Form defines the maximum expected deviation form of the
Gaus

calculated line.\" is very vague. The term \"form deviation\" should be

defined, and the formula by which it is calculated should be given.

90\. Page 75, Section 11.3.1

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The text should state explicitly:

1\. whether the MinRadiusOfCurvature may be zero,

2\. whether a negative MinRadiusOfCurvature is allowed, and

3\. what a negative MinRadiusOfCurvature signifies, if allowed.

If a negative MinRadiusOfCurvature is allowed, it might mean, for
example,

that the minimum occurs on a concavity while positive means the minimum

occurs on a convexity.

It would be simplest to require that MinRadiusOfCurvature be
non-negative.

91\. Page 75 and 76, Section 11.3.2 - Stopping

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

If

i\. the stop sphere is so small that the probe misses it entirely

   or passes through it between scan points, or

ii\. the stop sphere is entirely embedded in material so that the probe

   can never enter it,

then the stopping criterion will never be satisfied and the scan should

never stop. Occurrences of this seem likely. This is very bad behavior.

To fix this:

i\. The wording of the stopping rule should be changed to the following,

which will not fail if the probe passes through the sphere between scan

points.

   The DME will stop scanning when, after entering the stop sphere,

   some scan point is farther from the center of the sphere than the

   the previous scan point was from the center of the sphere.

ii\. It would be useful to have an additional stopping criterion, such
as a

second sphere that can be made large enough that it is unlikely to be

missed. Only an additional diameter would be needed to define a second

sphere.

92\. Page 75, Section 11.3.2 - n

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The ScanInPlaneEndIsPlane and ScanInPlaneEndIsCyl commands both have

an \"n  Number of through\" argument, but ScanInPlaneEndIsSphere does
not.

It is not clear if this is intentional or accidental. Intuitively, it

would seem that if the ScanInPlaneEndIsCyl command needs n, the

ScanInPlaneEndIsSphere should also need n.

93\. Page 75, Section 11.3.2 - Ei,Ej,Ek

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

No explanation is given of why the Ei,Ej,Ek vector is included in the

arguments to ScanInPlaneEndIsSphere. An explanation should be given or

Ei,Ej,Ek should be removed from the arguments.

94\. Page 77, Section 11.3.3 - stopping

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The stopping criterion may easily fail to be satisfied. An additional

stopping criterion would be helpful for safety.

95\. Page 77, Section 11.3.3 - end point

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Currently, the Ei,Ej,Ek argument is required to be the surface vector

at the end point, but no end point is given. Of what use is a surface

vector at an unknown point? The point Px,Py,Pz is any point on the

plane; why is this not required to be the end point? If the requirement

that it be the end point is added, the name should be changed to
Ex,Ey,Ez.

96\. Page 78, Section 11.3.4 - end point

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Currently, the Ei,Ej,Ek argument is required to be the surface vector

at the end point, but no end point is given. Of what use is a surface

vector at an unknown point? The point Cx,Cy,Cz is any point on the

axis of the stop cylinder; why is this not required to be the end point?

If the requirement that it be the end point is added, the name should be

changed to Ex,Ey,Ez.

97\. Page 79, Section 11.3.4

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Other sections with a stop sphere or stop cylinder have some version of

the following sentence at the end of the section. Intuitively, one would

expect the same sentence at the end of this section, but it is not
there.

If it has been omitted accidentally, add it.

   If the start point is within the stop cylinder, the DME will first

   leave the cylinder and then start checking the stop criterion.

98\. Page 79 - 81, Sections 11.3.5 and 11.3.6

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The instructions for what path to follow while executing the two
ScanOnCyl

commands are very vague. The only requirements are that the path be on
the

surface of the cylinder and that it start out in the direction from the

start point to the direction point. The figures make it appear that the

path is intended to be a helix. If this is the case, it should be

stated. If not, some other description of the path should be given. In
the

case of a helix, it would be helpful to add an integer parameter
indicating

the number (positive or negative) of full or partial counterclockwise
turns

to make around the helix before reaching the endpoint; without that
number

(or some equivalent information), the path is ambiguous. With the
number,

the direction point is not needed.

99\. Page 79, Section 11.3.5 - end point

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

The figure shows the center Ex,Ey,Ez of the stop sphere lying on the

cylinder, and the name sounds like the name of an end point, but the
text

does not require Ex,Ey,Ez to be the end point of the path. The text
should

require that, because if it is not the end point, Ei,Ej,Ek is a surface

vector at an unknown location.

100\. Page 80, Section 11.3.6 - end point

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Currently, the Ei,Ej,Ek argument is required to be the surface vector at

the end point, but no end point is given. Of what use is a surface
vector

at an unknown point? The point Px,Py,Pz is any point on the stop plane;
why

is this not required to be the end point?  If the requirement that it be

the end point is added, the name should be changed to Ex,Ey,Ez.

101\. Page 84, Section 12.1 - AlignPart data

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

It is not clear whether the p vectors and the m vectors are to be

returned in the data or only the p vectors.

102\. Page 96, Section A.6.6 - parameter vs. number

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

PtMeasPars has a Param for approach but real numbers for search and

retract. No explanation for this is given. It appears that search and

retract should also be of type Param.

103\. All of Appendix A

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

In general, much of the code is harder to read than it should be because
it

has not been formatted well. For example, Some of the C++ code is on
very

long lines that wrap around. This code should have line breaks so that
it

does not wrap around. Many spaces are excessively long. Indenting levels

are not used effectively. It would be helpful if the code were
re-formatted.

Part 2:

Minor Editorial Comments on Release 1.30 of the I++ DME Interface

T. Kramer

June 30, 2003

These comments are only minor editorial comments (spelling, punctuation,

grammar, copy and paste revision missed, etc.), all of which are
expected

to be completely uncontroversial. Most of these are from T. Kramer, but

a few are from Rene Keller and Marcel Lenherr.

1\. Page 3, Table of Contents

Change \"6.3.1.6 GetErrorInfo()\" to \"6.3.1.6 GetErrorInfo(..)\".

Unless all parentheses are deleted from section headings.

2\. Page 10, Section 1.7, last line

The first three sections said to have been added (6.2.3.13, 6.2.8, and

6.2.9) do not exist. Delete these section numbers from the list.

3\. Page 12, Section 2.2, picture

Change \"contiuous\" to something else (probably \"continuous\").

4\. Page 14, Section 2.4.2, title

The \"i\" in \"Monitor\" should be in boldface type but is not.

Adjust the font so the entire word \"Monitor\" is in boldface type.

5\. Page 23, Section 5.2

In the \"Server\" box at the upper left corner of Picture 12, change

\"StopDeamon\" to \"StopDaemon\" and change \"StopAllDeamons\" to
\"StopAllDaemons\".

6\. Page 23, Section 5.2

In the \"DME\" box at the left of Picture 12,

change \"ScanInCy lEndIsSphere\" to \"ScanInCylEndIsSphere\" and

change \"ScanInCy lEndIsPlane\" to \"ScanInCylEndIsPlane\"

7\. Page 23, Section 5.2

In the \"CartCMM\" box at the bottom left of Picture 12,

change \"SetCoordSy stem\" to \"SetCoordSystem\" and

change \"GetCoordSy stem\" to \"GetCoordSystem\".

8\. Page 27, Picture 16

The text in this picture is all crowded together and overlapping, so
that

it is hard to read. Fix the spacing so it is the same as the spacing
used

in Picture 15 on page 26.

9\. Page 27, Picture 16

Change \"GetErrorStatusE\" to \"GetErrStatusE\" and

change \"GetXtdErrorStatus\" to \"GetXtdErrStatus\".

10\. Page 33, Section 6.2.1, line 7

Change \"99999\" to \"09999\".

11\. Page 33, Section 6.2.1, line 10

Change \"send\" to \"sent\".

12\. Page 33, Section 6.2.1, line starting with \"00000\"

Change \"99999\" to \"09999\".

13\. Page 34, Section 6.2.1, first line of page

Change \"Examples of tags\" to \"Examples of Event tags\".

14\. Page 34, Section 6.2.1, next-to-last line of section

Change \"Ileagal\" to \"Illegal\".

15\. Page 35, Section 6.2.2.2, first line of page

Change \"Please not, that if\" to \"If\".

16\. Page 35, Section 6.2.2.2, fifth line of page

Change \"a equivalent\" to \"an equivalent\".

Also from Rene Keller

17\. Page 36, Section 6.2.3.1, middle column of table, eleventh box

Put double-quotes on each side of \"GoTo\", since it is supposed to be

a string.

18\. Page 36, Section 6.2.3.1, middle column of table, eleventh box

Change   (Move Out Of Limits))\"

to       \[Move Out Of Limits\]\")

Also from Rene Keller

19\. Page 36, Section 6.2.4.1, middle column of table

Change \"9\" to \"0500\" and change \"HealthCheck, Emergency button
activated\"

to \"\"Emergency Stop\"\".

20\. Page 37, Section 6.2.4.1, left column of table

Change \"X()Y()Z()\" to \"X(),Y(),Z()\".

I.e. insert two commas.

21\. Page 39, Section 6.3.1.5, last paragraph.

Fix the spacing of the text. Currently there are three problems with the

spacing:

a\. The third line is not right-adjusted, but all the other lines are.

b\. The fourth line is indented too far.

c\. There is a gigantic space on the fifth line that should not be
there.

22\. Page 39, Section 6.3.1.5, fourth line from end of page

Change \"aTransactionComplete\" to \"a TransactionComplete\".

23\. Page 40, Section 6.3.1.6, section heading

Change \"GetErrorInfo()\" to \"GetErrorInfo(..)\".

Unless all parentheses are deleted from section headings.

24\. Page 40, Section 6.3.1.6, second line

Change \"GetErrorInfo()\" to \"GetErrorInfo(..)\".

25\. Page 40, Section 6.3.1.7, in the table

Change \"00053\" to \"E0053\" in three places.

The 00053 tag is illegal for AbortE.

26\. Page 41, Section 6.3.1.7, middle column of table

On the second line of the top block (but not on the third line), change

the double quotes that look like 99 to double quotes that look like

66\.

27\. Page 41, Section 6.3.1.7, middle column of table

On the second line of the second block (but not on the fourth line),

change the double quotes that look like 99 to double quotes that look

like 66.

28\. Page 42, Section 6.3.1.9, third line

Change \"An enumeration of one or more of the following methods can be

argument\" to \"The argument list is an enumeration of one or more of

the following methods\".

29\. Page 42, Section 6.3.1.11, third line

Change \"An enumeration of one or more of the following methods can be

argument\" to \"The argument list is an enumeration of one or more of

the following methods\".

30\. Page 42, Section 6.3.1.12, Second sentence.

Put a period at the end of the sentence.

31\. Page 46, Section 6.3.2.11, fourth line

Change \"An enumeration of one or more of the following methods can be

argument\" to \"The argument list is an enumeration of one or more of

the following methods\".

32\. Page 47, Section 6.3.2.12, third line

Change \"An enumeration of one or more of the following methods can be

argument\" to \"The argument list is an enumeration of one or more of

the following methods\".

33\. Page 47, Section 6.3.2.13, fourth line

Change \"An enumeration of one or more of the following methods can be

argument\" to \"The argument list is an enumeration of one or more of

the following methods\".

34\. Page 49, Section 6.3.2.15, first line

Change \"return\" to \"be used as\".

35\. Page 50, Section 6.3.2.19, last sentence of section

Put a period at the end of the sentence.

36\. Page 51 and page 52, Section 6.3.2.23

Change the double-quote starting the string from one that looks like

99 to one that looks like 66 on each of the four lines with the names

\"NormalTool\", \"Conf1.Tip1\", \"Conf1.Tip2\", and \"SpecialTool\". The

double-quote starting \"ReferenceProbe\" is correct and should not be

changed.

37\. Page 52, Section 6.3.2.23, last line

Delete \"Errors of the enumerated methods\". There are no enumerated
methods.

38\. Page 53, Section 6.3.3, line 7

Put a period at the end of the line to end the sentence.

39\. Page 53, Section 6.3.3, line 9

Change \"measurment\" to \"measurement\".

40\. Page 53, Section 6.3.3, last line on the page

Change \"transfomation\" to \"transformation\".

41\. Page 54, Section 6.3.3, second line of text on the page

Change \"coeffizients\" to \"coefficients\".

42\. Page 54, Section 6.3.3.1, last sentence of section

Change \"considererd\" to \"considered\".

43\. Page 55, Section 6.3.3.3, last line of section

Change \"Section 10.4.2\" to \"Appendix A.4.2\".

44\. Page 55, Section 6.3.3.4, next-to-last line of section

Change \"Section 10.4.2\" to \"Appendix A.4.2\".

45\. Page 59, Section 6.3.6, line above next-to-last line of section

Delete the period after \"Min\".

46\. Page 59, Section 6.3.7, next-to-last paragraph, first line

Delete the period after \"Min\".

47\. Page 59, Section 6.3.7, last line

Change \"mannor\" to \"manner\".

48\. Page 60, Section 6.3.9, last line

Change \"garantees\" to \"guarantees\".

\>From Marcel Lenherr

49\. Page 63, Section 7.7, right column of table, first box

Change \"ActTools\" to \"ActTool\'s\"

50\. Page 67, Section 9.1, line starting with \"WP\"

Change \"proprietory\" to \"proprietary\".

51\. Page 67, Section 9.1, line starting with \"MI\"

Change \"proprietory\" to \"proprietary\".

52\. Page 70, Section 10, next-to-last line of non-bullet text

Change \"artefact\" to \"artifact\".

53\. Page 70, Section 10, last line of non-bullet text

Change \"measurment\" to \"measurement\".

54\. Page 71, Section 11.1.2, second line

Change \"OnScanReport()\" to \"OnScanReport(..)\".

55\. Page 71, Section 11.1.2, sixth line of Remarks

Change \"mark\" to \"marks\".

56\. Page 71, Section 11.1.2, seventh line of Remarks

Change \"tools\" to \"tool\'s\".

57\. Page 72, Section 11.2.2, description of i,j,k

Change \"vetor\" to \"vector\".

58\. Page 72, Section 11.2.2, second line of Remark

Change \"zero.The\" to \"zero. The\" (i.e. add missing space).

59\. Page 73, Section 11.2.2, seventh line of page

Change \"circulat\" to \"circular\".

60\. Page 73, Section 11.2.2, eighth line of page

Change \"cones.In\" to \"cones. In\" (i.e. add missing space).

61\. Page 73, Section 11.2.3, second line of section

Change \"displacement\" to \"angle\".

62\. Page 73, Section 11.2.3, third line of section

Change \"ScanOnCircle\" to \"ScanOnLine\".

63\. Page 73, Section 11.2.3, last line of section

Change \"Gaus\" to \"Gauss\".

64\. Page 74, Section 11.2.4, third paragraph from end of page, first
line

Change \"will scan a the distance\" to \"will scan along the line\".

65\. Page 74, Section 11.2.4, third paragraph from end of page, first
line

Change \"point..The\" to \"point. The\" (i.e. delete one of the two

periods and insert a space).

66\. Page 74, Section 11.2.4, third paragraph from end of page, second
line

Change \"greater the the distance\" to \"greater than the distance\".

67\. Page 74, Section 11.2.4, third paragraph from end of page, third
line

Change \"(Sx,Sy,Sy)\" to \"(Sx,Sy,Sz)\".

68\. Page 74, Section 11.2.4, second paragraph from end of page, second
line

Change \"stop\" to \"end\".

69\. Page 74, Section 11.2.4, last line of page

Change \"stop\" to \"end\".

70\. Page 75, Section 11.3.1, last line of section

Change \"minumum\" to \"minimum\".

71\. Page 75, Section 11.3.2, first line of section

Change \"contur\" to \"contour\".

72\. Page 75, Section 11.3.2, second line of section

Change \"criterium\" to \"criterion\".

73\. Page 75, Section 11.3.2, next-to-last line of page

Change \"arount\" to \"around\".

74\. Page 75, Section 11.3.2, next-to-last line of page

Delete the period at the end of the line.

75\. Page 75, Section 11.3.2, last line of page

Delete the comma after Ek.

76\. Page 76, Section 11.3.2, fifth line of Remark

Delete one of the two periods at the end of the sentence.

77\. Page 76, Section 11.3.2, last line of section

Change \"checking the stop criterium\" to \"check the stop criterion\".

78\. Page 76, Section 11.3.3, first line of section

Change \"contur\" to \"contour\".

79\. Page 76, Section 11.3.3, second line of section

Change \"criterium\" to \"criterion\".

80\. Page 77, Section 11.3.3, fifth line of Remark

Delete one of the two periods at the end of the sentence.

81\. Page 77, Section 11.3.3, next-to-last paragraph of section, last
line

Put a period at the end of the sentence.

82\. Page 77, Section 11.3.3, next-to-last line of section

Change \"when it moved\" to \"when it has moved\".

83\. Page 78, Section 11.3.4, first line of page

Change \"ScanInPlaneEndIsPlane\" to \"ScanInPlaneEndIsCyl\".

84\. Page 78, Section 11.3.4, first line of page

Change \"contur\" to \"contour\".

85\. Page 78, Section 11.3.4, second line of page

Change \"criterium\" to \"criterion\".

Also from Marcel Lenherr

86\. Page 78, Section 11.3.4, third line of page

Change \"dx,dy,dz\" to \"Dx,Dy,Dz\".

87\. Page 78, Section 11.3.4, sixth line of Parameters

Delete the period at the end of the line.

88\. Page 79, Section 11.3.5, first line of section

Change \"contur\" to \"contour\".

89\. Page 79, Section 11.3.5, second line of section

Change \"criterium\" to \"criterion\".

90\. Page 80, Section 11.3.5, last line of section

Change \"criterium\" to \"criterion\".

91\. Page 80, Section 11.3.6, first line of section

Change \"contur\" to \"contour\".

92\. Page 80, Section 11.3.6, second line of section

Change \"criterium\" to \"criterion\".

93\. Page 80, Section 11.3.6, eighth line of Parameters

Change \"defnes\" to \"defines\".

94\. Page 81, Section 11.3.6, next-to-last line of section

Change \"when it moved\" to \"when it has moved\".

95\. Page 82, Section 11.4.1, left column of table, fourth box

Change \"0,001\" to \"0.001\".

96\. Page 82, Section 11.4.1, middle column of table, tenth box

Change \"0,1614\" to \"0.1614\".

97\. Page 82, Section 11.4.1, right column of table, seventh box

Change \"Indizes\" to \"Arguments\".

98\. Page 82, Section 11.4.1, right column of table, seventh box

Change \"I\" to \"i\".

99\. Page 82, Section 11.4.2, right column of table, last line of page

Change \"Indizes\" to \"Arguments\".

100\. Page 83, Section 11.4.2, right column of table, next-to-last box

Change \"criteria is reached\" to \"criterion is satisfied\".

101\. Page 84, Section 12.1, third line of section

Change \"AlignPart1\" to \"AlignPart\".

102\. Page 84, Section 12.1, last sentence of Parameters

Change \"rotational equipments\" to \"pieces of rotational equipment\".

103\. Page 84, Section 12.1, next-to-last line of page

Change \"pane\" to \"plane\".

104\. Page 85, Section A.2.1, line declaring EndSession

Change \"disconnent\" to \"disconnect\".

105\. Page 87, Section A.2.3, first line on the page

Change \"confirme\" to \"confirm\".

106\. Page 87, Section A.2.3, fifth line on the page

Change \"confirme\" to \"confirm\".

107\. Page 88, Section A.3.1

Change \"GetErrorStatusE\" to \"GetErrStatusE\".

108\. Page 88, Section A.3.1

Change \"GetXtdErrorStatus\" to \"GetXtdErrStatus\".

109\. Page 90, Section A.4.2, in definition of EulerA::EulerA

Change \"calcalate\" to \"calculate\".

110\. Page 90, Section A.4.2, in definition of EulerA::EulerA

Change \"matriz\" to \"matrix\".

111\. Page 98, Section A.7.2, in definition of class EulerA

Change \"angel in degree\" to \"angle in degrees\".

112\. Pages 86, 87, 90, Appendix A

These pages have comments that are placed too far right, so that

they wrap around to the next line. These should be moved to the left

so they do not wrap around.