ISO 16284:2006

INTERNATIONAL ISO
STANDARD 16284
Second edition
2006-03-01
Ophthalmic optics — Information
interchange for ophthalmic optical
equipment
Optique ophtalmique — Échange d'informations pour l'équipement
d'optique ophtalmique
Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative reference . 1
3 Terms and definitions. 1
3.1 General terms. 1
3.2 Special characters . 2
3.3 Data types. 2
3.4 Messages. 3
3.5 Records. 4
3.6 Sessions . 4
3.7 Timeout . 5
4 Overview . 5
5 Requirements . 6
5.1 Records. 6
5.2 Reference point records . 8
5.3 Generator records. 9
5.4 Tracing records. 11
5.5 Tracing formats. 14
5.6 Packets . 18
5.7 Deprecated requirements . 21
6 Sessions . 22
6.1 General. 22
6.2 Initialization sessions. 22
6.3 Upload sessions . 30
6.4 Download sessions . 33
6.5 File-based information transfer. 34
7 Other requirements. 35
7.1 RS-232 Communications parameters. 35
7.2 Operator messages . 35
7.3 Host requirement . 35
Annex A (normative) Record labels . 36
Annex B (informative) Packed binary format example. 64
Annex C (informative) CRC calculation. 70

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 16284 was prepared by Technical Committee ISO/TC 172, Optics and photonics, Subcommittee SC 7,
Ophthalmic optics and instruments and by Technical Committee CEN/TC 170, Ophthalmic optics in
collaboration.
This second edition cancels and replaces the first edition (ISO 16284:2001), which has been technically
revised. Since the publication of the first edition in the year 2001, there have been a number of industry
developments. Specifically, surface coater, front surface generator, lens measuring, inspection and lap feeder
devices have all been developed. In order to communicate with these devices and to support new features on
existing device types, the maintenance committee has proposed a number of new labels and device types.
This revised International Standard also proposes a way of dealing with file-based data transfers between
devices and hosts. In addition, a number of clarifications has been made to further explain certain
requirements of the standard and deprecating several requirements because they have proved difficult to
manage in practice.
iv © ISO 2006 – All rights reserved

Introduction
This International Standard is the result of a desire shared by manufacturers of optical laboratory equipment
and producers of software used in optical laboratories to simplify the interconnection of their products.
The International Standard defined herein provides:
⎯ a method by which machines and computer systems conduct their exchanges of data;
⎯ a method by which computer systems can initialize such parameters on machines as the manufacturers
thereof allow;
⎯ a method by which machines can initialize computer systems with information that the systems can use
for various purposes;
⎯ a method by which a machine can inform a computer system as to what information it wants to receive,
thus allowing machines to define new interfaces dynamically;
⎯ a standard set of records and device types that are used to communicate agreed upon sets of information.
The last feature listed above requires that this International Standard be amended on a regular basis, as the
need for new data elements is inevitable.

INTERNATIONAL STANDARD ISO 16284:2006(E)

Ophthalmic optics — Information interchange for ophthalmic
optical equipment
1 Scope
This International Standard establishes a method by which machines and computer software systems used in
the fabrication of ophthalmic lenses can exchange information.
2 Normative reference
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 13666:1998, Ophthalmic optics — Spectacle lenses — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13666 and the following apply.
3.1 General terms
3.1.1
device
machine or instrument used in the fabrication of ophthalmic lenses that communicates with a computer
system to send or receive job information
3.1.2
host
computer system providing information to or receiving information from a device
3.1.3
job
order for prescription ophthalmic lenses or spectacles
3.1.4
download
communication session in which the host system transmits data to the device
3.1.5
upload
communication session in which the device transmits data to the host
3.2 Special characters
3.2.1
code separator
reserved character used to delimit codes in a device record
3.2.2
CRC position character
reserved character marking the location of the end of the data records and the start of the optional CRC
record within a packet
3.2.3
end character
reserved character marking the end of a packet
3.2.4
field separator
reserved character delimiting the fields in a record
3.2.5
label separator
reserved character separating the record label from the field(s) within a record
3.2.6
mandatory record flag
reserved character marking certain records as mandatory
3.2.7
start character
reserved character marking the beginning of a packet
3.2.8
record separator
reserved character which delimits records
3.2.9
unknown data indicator
reserved character indicating that data required for a particular field is unknown to the host
3.2.10
ACK character
reserved character indicating successful transmission of a packet
3.2.11
NAK character
reserved character indicating failed transmission of a packet
3.2.12
control character
character having an ASCII value of less than 32
3.3 Data types
3.3.1
limited data
text data limited to a maximum length
2 © ISO 2006 – All rights reserved

3.3.2
literal data
text data limited to a maximum length and specified in this International Standard
3.3.3
numeric data
floating-point and integer numbers
3.3.4
text data
strings of characters that have no pre-defined meaning
3.3.5
integer data
data represented in whole number form
3.3.6
binary data
data presented in a form usable by computer software with little or no translation
NOTE It requires special handling to avoid introduction of control characters.
3.4 Messages
3.4.1
message
structured stream of data transmitted from a host to a device or from a device to a host
3.4.2
confirmation message
message sent by the receiver of a packet and comprised of a single character indicating that the transmission
was successful
3.4.3
positive acknowledgement
single character message indicating successful reception of a sender's message
3.4.4
negative acknowledgement
single character message indicating unsuccessful reception of a sender's message
3.4.5
packet
structured message consisting of a start character and a series of records and terminated by an end character
3.4.5.1
data packet
packet sent from a device to a host or a host to a device, and containing requested information
3.4.5.2
request packet
packet sent from a device to a host to initiate a session
3.4.5.3
response packet
packet containing status information
3.5 Records
3.5.1
record
structured stream of characters including a record label, a label separator, zero or more data fields separated
by field separators and a terminating record separator
3.5.2
data field
single data element within a record
3.5.3
record label
means of identifying data contained in a record, limited in length to 8 characters and not including spaces or
reserved characters defined in this International Standard
NOTE A list of device record labels is in Annex A.
3.5.4
ASCII record
record comprised of ASCII characters and conforming to the structures defined herein
3.5.5
binary record
record comprised of bytes encoded using the binary number system
3.5.6
chiral record
record with two fields, one for a data element for a right lens or eye, and one for a left, arranged in the order
right then left
3.5.7
CRC record
record at the end of any packet containing a CCITT CRC-16 cyclical redundancy check value calculated on
the characters transmitted
3.5.8
device record
record containing job specific data elements conveyed between devices and hosts
3.5.9
interface record
record supporting the operation of the host-device interface and not containing job-specific data
3.6 Sessions
3.6.1
session
sequence of messages passed between a device and a host that serves to exchange information related to a
single order or task
3.6.2
initialization session
specialized session allowing devices to provide hosts with information that would otherwise be included with
each request, such as machine model, software version and operator ID

1) Comité Consultatif International Téléphonique et Télégraphique
4 © ISO 2006 – All rights reserved

3.6.2.1
auto-format initialization
initialization session allowing devices to define sets of device records to be requested from hosts
3.6.2.2
preset initialization
initialization session allowing devices to transmit sets of identifying data to hosts
3.6.3
download session
session in which information is passed from a host to a device
3.6.4
upload session
session in which information is passed from a device to a host
3.6.5
INFO session
upload request packet containing job status information used to indicate the completion of a job by a device
3.6.6
MNT session
upload request packet containing vendor specific device information
3.7 Timeout
3.7.1
timeout
numeric value representing that period of time that a host or device shall wait for the arrival of data, after
which it assumes that such data will not be forthcoming
3.7.1.1
confirmation timeout
timeout which applies to the reception of the confirmation message
3.7.1.2
intercharacter timeout
timeout which applies to the interval between successive characters in a stream of data
3.7.1.3
packet timeout
timeout which applies to the reception of a packet
4 Overview
The strategy used in this International Standard for the exchange of data between devices and hosts can be
expressed as follows.
A machine used in the fabrication of ophthalmic lenses (a device) sends a request to a computer system (a
host), indicating a need to do one of the following:
⎯ initialize information to identify the device, software versions, model numbers, etc.;
⎯ upload to the host, information for it to store and/or use in the processing of ophthalmic prescription
orders;
⎯ download from the host, information required by the device for it to perform its tasks.
Communication can be initialized in two ways. The device may begin an initialization session or the host can
force the device to do so by refusing to accept a normal request and asking for initialization via a special error
response. For upload requests, the host acknowledges the request and the device sends its data, the receipt
of which the host acknowledges. For download requests, the host responds to the request with the data
requested.
The variable-length packets of data that comprise this exchange consist of a series of records, each of which
contains data and a label identifying the data. This International Standard defines a set of labels and
characterizes the data associated with each. This set of labels shall be expanded as needed in the future.
An exchange of packets related to a single job is called a session. The structure of these sessions and the
packets of records of which they are comprised is the subject of this International Standard.
Although this International Standard was conceived as being implemented on point-to-point RS-232 serial
links, it could be implemented on other hardware platforms. As this is done, specifications shall be
incorporated into this International Standard so as to maximize interconnectability amongst diverse hosts and
devices.
In the examples given in this International Standard, in the interests of legibility, the RECORD SEPARATORS
may be omitted, the START CHARACTER may be placed on a separate line and CRC RECORDS may be
excluded. Remarks have been included as REM records. Comments are enclosed in square brackets ([ … ])
and are not part of the data stream. Ellipses (“…”) are used to indicate more data of the same type as
precedes and follows the ellipses. SPACES have been inserted around record and field separators for
readability; in practice these should not be included in packets as this needlessly decreases the efficiency of
expression. In the descriptions of Clause 5, REQUEST, RESPONSE and DATA refer to packets. Since
encoded data are always expressed using the point as the decimal sign, to avoid confusion the decimal sign is
used throughout this document although the ISO decimal sign is the comma. Furthermore, the space
representing the thousandths separator is not given in the encoded data.
5 Requirements
5.1 Records
5.1.1 Interface records
This International Standard defines a set of interface records. These records contain information which the
host and device use to communicate. They do not contain job-specific data. These records are enumerated
in A.2.
5.1.2 Device records
This International Standard defines a set of device records which identify the data elements that might be
required by any of the devices that might be required for the fabrication of a job. These records are
enumerated in A.1.
5.1.3 Preset device types
This International Standard further identifies subsets of device records that are deemed to be appropriate for
specific types of devices. These preset records are enumerated in A.3.
5.1.4 Records with unknown values
If the host is requested to send any record for which it has no information or partial information, it shall send
the record with a question mark “?” in all the unknown data fields in order to indicate that the information is not
available. Such records shall be properly formatted according to the rules for chiral records.
6 © ISO 2006 – All rights reserved

5.1.5 Ignored records
Whenever a host or device receives a record with a label it does not recognize, it shall ignore the record.
5.1.6 Experimental records
When a machine vendor wishes to test new records prior to submitting them for inclusion in this International
Standard, such records should use labels that begin with an underscore character (ASCII “_”, decimal 95).
Record labels are limited in length to 8 characters and may not include spaces or reserved characters defined
in this International Standard.
5.1.7 Reserved characters
5.1.7.1 Control characters and the additional characters specified may not appear in transmitted data
streams except as specified. The set of reserved characters is specified in Table 1.
5.1.7.2 Reserved characters shall appear in ASCII records only to provide the functionality that they are
assigned, as in the case of record and field separators. Reserved characters which conform to the definition of
text data may also appear in text fields.
5.1.7.3 When a reserved character with a decimal value less than 32 appears in a binary record, it shall
be “escaped” in the following manner. In place of such a character, two characters shall be sent. The first
character shall be an ESC character followed by the original character with its high bit set, i.e. the character is
OR'd with decimal 128, hex 0×80. The receiver, on receipt of an ESC character, shall discard the ESC
character and clear the high bit of the following character. The CRC value, if present, shall be determined after
such reserved characters are escaped, so that a receiver need not process packets prior to validating a
received packet's CRC.
NOTE In other words, the transmitter encodes control characters before calculating the CRC, and the receiver
calculates the CRC before decoding them.
EXAMPLE A stream of bytes (a short tracing record in absolute binary form) before and after having been “escaped”
as described above.
Before:
R=175 9 23 10 45 10 223 9 90 9 205 8 89 8 252  7 183  7 143  7
130 7 147  7 197  7 24 8 136 8 18 9 167 9 39 10 85 10 19 10
213 9 146  9 75  9 14 9 199 8 120 8 38 8 222  7 166  7 131  7
117 7 122  7 149  7 191 7 241 7 41 8 92 8 152  8 229  8 67  9
After:
R=175 9 23 27 138 45 27 138 223 9 90 9 205 8 89 8 252  7 183  7 143  7
130 7 147 7 197  7 24 8 136 8 18 9 167 9 39 27 138 85 27 138 27 147 27 138
213 9 146 9  75  9 14 9 199 8 120 8 38 8 222  7 166  7 131  7
117 7 122 7 149  7 191 7 241 7 41 8 92 8 152  8 229  8 67  9
5.1.7.4 Limited data are a string of ASCII characters in the range 32 to 127 decimals excluding 59
(semi-colon). The length of this string is limited to 12 characters.
5.1.7.5 Text data are a string of ASCII characters in the range 32 to 127 decimals excluding 59
(semi-colon) and having no predefined meaning. The length is limited to 80 characters.
5.1.7.6 Literal data is a string of ASCII characters in the range 32 to 127 whose meaning is implied by the
record type and specified in this International Standard. Length is limited to 12 characters unless otherwise
noted in the record definition. Literal data shall not contain reserved characters defined by the interface
(see Table 1). Literal data is case sensitive.
5.1.8 Record length
Non-binary records should not exceed 80 characters in length. Binary data may be longer than 80 characters.
Table 1 — Reserved characters
Hexadecimal Decimal
Character Control key Use
value value
FS 0×1C 28 ^\ Start of message
GS 0×1D 29 ^] End of message
DC1 0×11 17 ^Q Reserved (XOFF)
DC3 0×13 19 ^S Reserved (XON)
ACK 0×06 06 ^F Positive acknowledgement
NAK 0×15 21 ^U Negative acknowledgement
ESC 0×1B 27 ^[ Escape
RS 0×1E 30 ^^ CRC separator
SUB 0×1A 26 ^Z DOS end-of-file marker
CR 0×0D 13 ^M Record separator
LF 0×0A 10 ^J Record separator
; 0×3B 59 ; Field separator
= 0×3D 61 = Label separator
, 0×2C 44 , Code separator
* 0×2A 42 * Mandatory record flag
? 0×3F 63 ? Unknown data indicator
5.2 Reference point records
5.2.1 Records are defined to indicate the horizontal and vertical distances between two reference points or
to indicate an action that a machine should take relative to a reference point. The following naming scheme
will clarify all such reference records included in this International Standard and can easily be extended for
future ones.
5.2.2 The first two letters of the record label describe the first reference point (see Table 2), the second two
letters of the record label describe the second reference point and the last two letters indicate “IN” (horizontal)
or “UP” (vertical) directions (see Table 3). The values indicate the position of the second reference point with
respect to the first reference point.
5.2.3 A positive IN value indicates that the second reference point is towards the nasal relative to the first.
5.2.4 A negative IN value indicates that the second reference point is towards the temporal relative to the
first.
5.2.5 A positive UP value indicates that the second reference point is above the first.
5.2.6 A negative UP value indicates that the second reference point is below the first.
8 © ISO 2006 – All rights reserved

Table 2 — Reference point identifiers
Identifier Reference point
BC Blank centre
FB Finish block
FC Frame centre
OC Optical centre/prism reference point
SB Surface block
SG Segment/progressive fitting cross (layout reference point)

Table 3 — Reference point records
Label Meaning
FBFCIN, FBFCUP Finish block to frame centre (see Table A.1 for use)
FBSGIN, FBSGUP Finish block to segment
FBOCIN, FBOCUP Finish block to prism reference point (O.C.)
SBBCIN, SBBCUP Surface block to blank centre
BCSGIN, BCSGUP Blank centre to segment
BCOCIN, BCOCUP Blank centre to prism reference point (O.C.)
SBSGIN, SBSGUP Surface block to layout reference point (segment)
SBOCIN, SBOCUP Surface block to prism reference point (see 5.3.11 for use)
SBFCIN, SBFCUP Surface block to frame centre
SGOCIN/SGOCUP Segment to O.C.
FCSGIN/FCSGUP Frame centre to segment (similar to segment height or drop)
FCOCIN/FCOCUP Frame centre to O.C. (similar to O.C. height or drop)
5.3 Generator records
5.3.1 The surface generator interface includes a number of records used to indicate adjustments that
should be applied to the generator machine settings. Because this International Standard provides for a
complete data set (“preset packet”) to be sent to an “unknown” generator, it is necessary to clarify some of the
relationships amongst these records, especially as relates to the “compensation” fields.
The position of a lens in a generator can be determined by the RNGH, RNGD, SAGRD and SAGBD fields
(ring height, ring diameter, lens sag at ring diameter and lens sag at blank diameter, respectively). Some
generators, especially those with exclusively mechanical components, may presume certain values for some
of the above records and may be unable to effect the adjustments required by the mismatch in assumptions.
The following compensation fields provide the data required to make these adjustments.
5.3.2 BLKCMP represents the change that is required to be made to the generator thickness setting that
arises from a mismatch between the curvature of a block that has a curved contact surface with the lens and
the curvature of the lens blocked thereon. The BLKB field contains the curvature of that surface of the block
that contacts the lens; the BLKD field contains the diameter of the block.
5.3.3 When the blocks used for a job do not have a curved contact surface, the BLKB field is not necessary.
If it is sent in such a case, its value should be equivalent to IFRNT.
5.3.4 RNGCMP represents the change that is required to be made to the generator thickness setting that
arises from a mismatch between the blocking ring height and/or diameter, known to the host, and that which is
presumed by the generator.
5.3.5 FINCMP indicates the amount of thickness that should be added to the generator setting to allow for
material removed during fining (smoothing) and polishing.
5.3.6 THKCMP shall be used for such compensations to thickness as may be required, which are not
otherwise handled by the records defined in this International Standard (the thickness compensation fields
apply equally to GTHK and OTHK).
5.3.7 EECMP indicates a dioptre amount that shall be added to the GCROS and GCROSX values when
elliptical error compensation is required.
5.3.8 A host can maintain complete control over the settings on a generator by including all of the
compensation values that it believes to be required by a particular machine in the basic setting records and
sending zero values in the compensation records; e.g. sum GCROS with EECMP, send the result as GCROS
and send EECMP with values equal to zero.
5.3.9 In compensation records, zero values indicate that the host does not want the machine to apply any
compensation that it may be capable of being set to do.
5.3.10 The ABSENCE of compensation fields indicates that the generator should apply such compensations
as it may be set to do.
5.3.11 For prism versus decentration, the fields GPRVM and GPRVA represent prism magnitude and
direction to be generated. These values shall include all possible contributions to prism, including Rx
(prescription) prism, thinning prism, and prism for decentration. The fields SBOCIN and SBOCUP express
vector distances to which the grinding centre is to be offset from the surface block centre, laterally and
vertically. In order that both be expressed in a single packet, as would be desirable in the case of a “generic”
GEN request, a set of prism records is defined, RPRVM and RPRVA, which represents prism to be ground
exclusive of the decentration expressed in SBOCIN/SBOCUP. In addition, when decentration is expressed
directly (via SBOCIN/SBOCUP), the OTHK value should be present. The following rules describe how these
fields should be aggregated.
5.3.11.1 When expressing decentration to be generated as prism, the following fields are used together:
GPRVM, GPRVA and GTHK.
5.3.11.2 When expressing decentration to be generated directly, the following fields are used together:
RPRVM, RPRVA, SBOCIN, SBOCUP and OTHK.
5.3.11.3 Because the method described in 5.3.11.1, in which decentration is expressed in the form of
prism, is the more universal one for expressing decentration to be ground, the set of records described therein
should be supported by all generators and hosts. The set of records described in 5.3.11.2, in which
decentration is expressed as vectors, should be included in addition to the 5.3.11.1 set. Generators not
supporting the vector method can safely ignore the vector fields.
5.3.12 For pad thickness, the inclusion of the PADTHK record indicates that LAP curves cut by a generator
should be compensated for the thickness of the pad. No compensation should be made to the lens curves
expressed in GBASE/GCROS or GBASEX/GCROSX. It is the responsibility of the host to determine such
compensations as shall be applied to generator curves, the need for which may result from the use of laps not
compensated for pad thickness, or the desire to fine lenses from edge to centre.
5.3.13 For curve signs, concave curves shall be expressed as negative numbers and convex curves as
positive numbers. One implication of this is that for generators that cut laps, the lens curves and lap curves
shall have opposite signs.
10 © ISO 2006 – All rights reserved

5.4 Tracing records
5.4.1 Expression of trace data
Trace data begins with a TRCFMT record that specifies the format in which the tracing is to be expressed, the
number of points to be transmitted, whether the radii are equiangular, the orientation of the tracing and an
indication of what was traced.
A device indicates its desire to upload or download trace data by including one or more TRCFMT records in
either its initialization packet, or, if no initialization is done, its request packet. All supported formats and
numbers of points are listed in the order of the device's preference. It is not necessary to include every
combination of side specifiers (B, R, and L); because of the requirement specified in 5.4.13, only the device's
preferred mode need be specified. Devices that neither upload nor download trace data do not include any
TRCFMT records in their initialization or request packets. The same rules apply to sag data and ZFMT.
When trace data is expected by a device, but unavailable from the host, a special form of the TRCFMT record
is sent, composed of a single field with the integer value 0. When trace data is available, but sag data is not, a
similarly-formed ZFMT record is sent by the host. When TRCFMT=0 is sent, ZFMT=0 is implied and not
required. When two sides of radius data are sent, for which sag data are unavailable, a ZFMT=0 record
should follow each set of radius data. In the case that two-side data has been negotiated, and only a single
side is sent, TRCFMT=0 is not sent for the missing side.
EXAMPLE 1 Trace data requested by device, but unavailable from host:
TRCFMT=0
EXAMPLE 2 Trace data requested by device and available from host, Z data requested, but unavailable:
TRCFMT=1;400;E;R;F
R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935
R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579

R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579
ZFMT=0
5.4.2 Radius data
These are contained in “R” records. Sag data is contained in “Z” records. Angle data for radius data is
contained in “A” records and for sag data in ZA records. For the ASCII format, all of the records follow the
80-character line limit rule, therefore there may (in fact, will likely) be multiple R, A, Z and ZA records for each
tracing. For BINARY data, the line limit rule will not apply and there will be only one R, A, Z and ZA record as
needed. Radius and sag data is expressed in hundredths of a degree with an implied decimal point.
EXAMPLE Radius data:
a) ASCII format
TRCFMT=1;400;E;R;F
R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935
R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579
etc…
b) Binary formats
TRCFMT=2;400;E;R;F
R=
5.4.3 Uneven angles
When these are specified in the TRCFMT record, angle data is required. It shall appear immediately after its
corresponding radius data. Angle data is contained in one or more “A” records, and shall be expressed in the
same format as the radius data to which it corresponds. Angle data is expressed hundredths of a degree with
an implied decimal point and shall be in the range 0 to 35999.
NOTE Angle data can also follow the sag data if uneven angles are specified for the sag data.
5.4.4 ZFMT
The sag data format record, ZFMT, has exactly the same definition as the TRCFMT record. The same rules
apply to angle data for sag data as to angle data for radius data.
5.4.5 “R” records
These shall appear immediately after the TRCFMT record. All of the “R” records for a tracing (i.e. a single side,
when two are provided) appear together. Each side has its own TRCFMT record.
5.4.6 “Z” records
These shall appear immediately after the ZFMT record. All of the “Z” records for a tracing (i.e. a single side,
when two are provided) appear together. Each side has its own ZFMT record.
5.4.7 “A” or ZA records
These, when present, shall appear immediately after their corresponding set of “R” or “Z” records. ZFMT and
“Z” records shall appear immediately after their corresponding TRCFMT and “R” records.
EXAMPLE A two-eye tracing data set (abbreviated) showing the required sequence of records:
TRCFMT=1;400;U;R;F
R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935
R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579
…
R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371
A=0;90;180;270;360;450;540;630;720;810
A=900;990;1080;1170;1260;1350;1440;1530;1620;1710
…
A=35100;35190;35280;35370;35460;35550;35640;35730;35820;35910
ZFMT=1;100;U;R;F
Z=322;331;342;328;314;308;300;295;288;280
…
Z=316;318;324;328;333;343;349;352;357;362
ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240
…
ZA=32400;32760;33120;33480;33840;34200;34560;34920;35280;35640
TRCFMT=1;400;U;L;F
R=2517;2450;2379;2318;2247;2168;2086;2014;1958;1923
R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371
…
R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579
A=0;90;180;270;360;450;540;630;720;810
A=900;990;1080;1170;1260;1350;1440;1530;1620;1710
…
A=35100;35190;35280;35370;35460;35550;35640;35730;35820;35910
ZFMT=1;100;U;R;F
Z=322;331;342;328;314;308;300;295;288;280
12 © ISO 2006 – All rights reserved

…
Z=316;318;324;328;333;343;349;352;357;362
ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240
…
ZA=32400;32760;33120;33480;33840;34200;34560;34920;35280;35640
5.4.8 Frame tracings
These shall be centred geometrically when presented to the host. The host may decentre the shape in order
to produce a certain effect on a device.
5.4.9 Frame sizing
5.4.9.1 BSIZ and CSIZ records indicate that devices shall modify the dimensions of the received trace by
the amount specified.
5.4.9.2 Non-zero values shall not be supplied for both BSIZ and CSIZ.
5.4.9.3 HBOX, VBOX and CIRC records shall reflect the dimensions of the shape sent in R records.
5.4.9.4 In the particular case where BSIZ and CSIZ are absent or unknown and a single side tracing and
two CIRC values which differ are received, the CIRC for the eye sent should reflect the shape. CSIZ is implied
to be the difference between the two circumferences and the shape for the eye not sent shall be modified
according to the implied CSIZ.
5.4.10 Tracing data
These shall be expressed so that the first radius is at zero degrees (3 o'clock on standard polar scale) and
shall proceed anti-clockwise. When angle data are provided, the starting radius shall be the one at the first
available meridian greater than or equal to zero.
5.4.11 Eye orientation
5.4.11.1 Eye orientation, right or left, shall be viewed as a refractionist views a spectacle wearer; right-eye
oriented data therefore start at the nasal side while left-eye data start at the temporal.
5.4.11.2 Eye orientation may be established during initialization. If it is not, it is specified in the devices'
request packet.
5.4.11.3 When eye R (right) is specified, the device wants to send or receive a single set of trace data with
right-eye orientation.
5.4.11.4 When eye L (left) is specified, the device wants to send or receive a single set of trace data with
left-eye orientation.
5.4.11.5 When eye B (both) is specified, the device wants to send or receive both right and left sets of
tracing data, each in the appropriate orientation.
5.4.12 Eye orientation during tracing transmission
5.4.12.1 When eye R (right) is specified in the TRCFMT or ZFMT records, the tracing will have RIGHT eye
orientation.
5.4.12.2 When eye L (left) is specified in the TRCFMT or ZFMT records, the tracing will have LEFT eye
orientation.
5.4.12.3 Eye B shall not be specified in data packets, only in request or initialization packets. In data
packets in which both sides are included, there shall be two TRCFMT records, one for each side, labelled
appropriately.
5.4.13 Trace orientation acceptance
Hosts and devices shall handle the reception of either orientation of tracing data without generating an error
condition. Hosts should make an effort to provide data in the quantity and orientation requested by the device
when possible.
5.4.14 Sag data
In the expression of sag data, the smallest number in the data set shall be positive and shall represent the
point located furthest toward the front of the frame or lens. The distances from this point to other points in the
data set shall have positive values in increments of 0.01 mm.
5.5 Tracing formats
5.5.1 Example data
It is strongly recommended that devices be consistent in the representations of data. While it is not expressly
forbidden, representing radius data in one orientation and sag data in another, might violate host systems'
programmers unwarranted assumptions and fail.
The following small sample tracing, comprised of 40 radii, is used for the examples below. The sample is not
formatted in any particular way; it is just a list of the radius values used in the examples given in 5.5.2 to 5.5.6.
24.79, 25.83, 26.05, 25.27, 23.94, 22.53, 21.37, 20.44, 19.75, 19.35,
19.22, 19.39, 19.89, 20.72, 21.84, 23.22, 24.71, 25.99, 26.45, 25.79,
25.17, 24.50, 23.79, 23.18, 22.47, 21.68, 20.86, 20.14, 19.58, 19.23,
19.09, 19.14, 19.41, 19.83, 20.33, 20.89, 21.40, 22.00, 22.77, 23.71
5.5.2 ASCII absolute format
In this format, each radius is presented as a 4-digit decimal number in hundredths of a millimetre with an
implied decimal point. Each value is separated by a field separator (semi-colon). Data shall follow the
80-character line limit rule, therefore multiple “R” records are required for a single radius data set.
EXAMPLE A tracing expressed in format #1, ASCII absolute, requires 196 bytes of radius data (including the
semi-colons).
TRCFMT = 1;40;E;R;F
R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935
R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579
R=2517;2450;2379;2318;2247;2168;2086;2014;1958;1923
R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371
5.5.3 Binary absolute format
In this format, each radius is expressed as a 16-bit integer with the radius in hundredths of a millimetre. The
entire data set is contained within a single ra
...