ISO 16284:2001
(Main)Ophthalmic optics - Information interchange for ophthalmic optical equipment
Ophthalmic optics - Information interchange for ophthalmic optical equipment
Optique ophtalmique — Échange d'informations pour l'équipement d'optique ophtalmique
La présente Norme internationale établit une méthode permettant aux machines et aux systèmes informatiques utilisés dans la fabrication de lentilles ophtalmiques d'échanger des informations.
General Information
Relations
Frequently Asked Questions
ISO 16284:2001 is a standard published by the International Organization for Standardization (ISO). Its full title is "Ophthalmic optics - Information interchange for ophthalmic optical equipment". This standard covers: La présente Norme internationale établit une méthode permettant aux machines et aux systèmes informatiques utilisés dans la fabrication de lentilles ophtalmiques d'échanger des informations.
La présente Norme internationale établit une méthode permettant aux machines et aux systèmes informatiques utilisés dans la fabrication de lentilles ophtalmiques d'échanger des informations.
ISO 16284:2001 is classified under the following ICS (International Classification for Standards) categories: 11.040.70 - Ophthalmic equipment. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 16284:2001 has the following relationships with other standards: It is inter standard links to ISO 2598-1:1992, ISO 16284:2006. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 16284:2001 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 16284
First edition
2001-06-01
Ophthalmic optics — Information
interchange for ophthalmic optical
equipment
Optique ophtalmique — Échange d'informations pour l'équipement optique
ophtalmique
Reference number
©
ISO 2001
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.
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.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2001 – All rights reserved
Contents Page
Foreword.iv
Introduction.v
1 Scope .1
2 Normative reference .1
3 Terms and definitions .1
3.1 General.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.10
5.4 Tracing records.11
5.5 Packets .18
6 Sessions .21
6.1 General.21
6.2 Initialization sessions.21
6.3 Upload sessions .29
6.4 Download sessions .31
7 Other requirements.32
7.1 RS-232 Communications parameters.32
7.2 Operator messages .32
Annex A (normative) Record labels .33
Annex B (informative) Packed binary format example.55
Annex C (informative) CRC calculation.61
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 3.
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 International Standard may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 16284 was prepared by Technical Committee ISO/TC 172, Optics and optical
instruments, Subcommittee SC 7, Ophthalmic optics and instruments.
Annex A forms a normative part of this International Standard. Annexes B and C are for information only.
iv © ISO 2001 – 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:2001(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 normative document contains provisions which, through reference in this text, constitute provisions of
this International Standard. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this International Standard are encouraged to
investigate the possibility of applying the most recent edition of the normative document indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO 13666:1998, Ophthalmic optics — Spectacle lenses — Vocabulary.
3 Terms and definitions
For the purposes of this International Standard, the terms and definitions given in ISO 13666 and the following
apply.
3.1 General
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
special character used to delimit codes in a device record
3.2.2
CRC position character
special 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
special character marking the end of a packet
3.2.4
field separator
special character delimiting the fields in a record
3.2.5
label separator
special character separating the record label from the field(s) within a record
3.2.6
mandatory record flag
special character marking certain records as mandatory
3.2.7
start character
special character marking the beginning of a packet
3.2.8
record separators
special characters which delimit records
3.2.9
reserved characters
set of characters reserved for special functions
3.2.10
unknown data indicator
special character indicating that data required for a particular field is unknown to the host
3.2.11
ACK character
special character indicating successful transmission of a packet
3.2.12
NAK character
special character indicating failed transmission of a packet
3.3 Data types
3.3.1
limited data
text data limited to a maximum length
2 © ISO 2001 – 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 special
characters defined in this International Standard
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
3.6.2.1
auto-format initialization
initialization session allowing devices to define sets of device records to be requested from hosts
4 © ISO 2001 – All rights reserved
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
4Overview
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 substance 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.
5 Requirements
NOTE In the examples 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 below, REQUEST, RESPONSE and DATA refer to packets.
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 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 in turn 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 are enumerated in A.3.
5.1.4 Mandatory records
Records that are mandatory are so designated in their definitions. Records not so designated may be presumed to
be optional.
5.1.5 Records with unknown values
If the host is requested to send any mandatory record for which it has no 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.
5.1.6 Ignored records
Whenever a host receives a record with a label it does not recognize, it shall ignore the record.
6 © ISO 2001 – All rights reserved
5.1.7 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 special characters defined in this International
Standard.
5.1.8 Reserved characters
5.1.8.1 Control characters and the additional characters specified may not appear in transmitted data stream
except as specified. The set of reserved characters is specified in Table 1.
5.1.8.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, which are delimited by double quote characters.
5.1.8.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’dwith
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 7147 7197 724813681891679391085101910
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 71477197 72481368189167939 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.8.4 Limited data is a string of ASCII characters in the range 32 to 127 decimal. The length is limited to
12 characters. Limited data shall be enclosed in double quotation marks (ASCII 34 decimal). Limited data shall not
contain quotation marks.
5.1.8.5 Text data is a string of ASCII characters in the range 32 to 127 decimal having no predefined meaning.
Length is limited to 80 characters. Text data shall be enclosed in double quotation marks (ASCII 34 decimal). Text
data shall not contain quotation marks.
5.1.8.6 Literal data is a string of characters 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 special characters defined by the interface. No double quotation marks are needed.
Table 1 — Reserved characters
Hexadecimal Decimal Control
Character Use
Value Value Key
FS 0�1C 28 ^\ Start of message
GS 0�1D 29 ^] End of message
DC1 0�11 17 ^Q Reserved (XOFF)
DC3 19 ^S Reserved (XON)
0�13
ACK 0�06 06 ^F Positive acknowledgement
NAK 0�15 21 ^U Negative acknowledgment
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
= 61 = Label separator
0�3D
@ 0�40 64 @ Reserved
, 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, 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. 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 2001 – 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
Table 3 — Reference point records
Label Meaning
FBFCIN, FBFCUP Finish block to frame centre
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 optical centre
SBSGIN, SBSGUP Surface block to segment
SBOCIN, SBOCUP Surface block to prism reference point
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.
NOTE The above-enumerated 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 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 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.
10 © ISO 2001 – All rights reserved
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 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 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.
5.4 Tracing records
5.4.1 Expression of trace data
This begins with a TRCFMT record, which 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.
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-35999.
NOTE Angle data may 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
…
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
12 © ISO 2001 – All rights reserved
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 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.10 Eye orientation
5.4.10.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.10.2 Eye orientation may be established during initialization. If it is not, it is specified in the tracer’s request
packet.
5.4.10.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.10.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.10.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.11 Eye orientation during tracing transmission
5.4.11.1 When eye R (right) is specified in the TRCFMT or ZFMT records, the tracing will have RIGHT eye
orientation.
5.4.11.2 When eye L (left) is specified in the TRCFMT or ZFMT records, the tracing will have LEFT eye
orientation.
5.4.11.3 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, labeled appropriately.
5.4.12 Hosts and devices
These shall handle the reception of either orientation of tracing data without generating an error condition.
5.4.13 Tracing format example 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 distance from this point to other points in the data set
shall have positive values in increments of 0,01 mm.
NOTE 1 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.
NOTE 2 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 that follow.
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.4.14 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.4.15 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 radius data record.
NOTE Each binary 8-bit byte in the following examples is represented by one or more decimal digits separated from the
next byte by a space. Semi-colons are used to separate the individual radii. The semi-colons and spaces are not part of the
actual binary record.
EXAMPLE A tracing expressed in format #2, binary absolute, requires 86 bytes including the escape characters. The first
example shows the data prior to the escape process (described in 5.1.8.3) having been applied, the second, afterwards. The
escape sequences are shown in bold.
TRCFMT = 2;40;E;R;F
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
TRCFMT = 2;40;E;R;F
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.4.16 Binary differential format
In this format, the starting radius is represented as a two-byte integer, as in format 2. Each radius thereafter is
represented in a single signed byte as the difference between the current radius and the previous one. The data
values expressed are therefore equal to the previous radius subtracted from the current. If the differential cannot be
represented by signed byte, whose value must be between �127 and �127, a special value (hexadecimal 0�80,
� 128 decimal) is used to indicate that the next radius is expressed in absolute (i.e., 16-bit) form. The radius
immediately following the 16-bit value is then represented in differential form.
14 © ISO 2001 – All rights reserved
EXAMPLE A tracing expressed in format #3, binary differential, requires 54 bytes including the escape characters. As
above, the first example shows the data prior to the escape process (described in 5.1.8.3) having been applied, the second,
afterwards. In the first example, the absolute radii flags are shown in bold. In the second, the escape sequences are shown in
bold.
TRCFMT = 3;40;E;R;F
R=175 9; 104; 22; -78;-128 90 9;-128 205 8;-116; -93;
-69; -40; -13; 17; 50; 83; 112;-128 18 9;-128 167 9;
-128 39 10; 46; -66; -62; -67; -71; -61; -71; -79; -82;
-72; -56; -35; -14; 5; 27; 42; 50; 56; 51; 60; 77; 94
TRCFMT = 3;40;E;R;F
R=175 9; 104; 22; -78 ;-128 90 9;-128 205 8;-116; -93;
-69; -40; -13; 27 145; 50; 83; 112;-128 18 9;-128 167 9;
-128 39 27 138; 46; -66; -62; -67; -71; -61; -71; -79; -82;
-72; -56; -35; -14; 5; 27 155; 42; 50; 56; 51; 60; 77; 94
5.4.17 Packed binary format
This is the most efficient, and most complex, method for the expression of shape information. To facilitate
implementation of this format, a complete example is included in annex B.
Three data types are defined:
� absolute, in which sixteen-bit "words" are used to express values in the range � 327,67 mm to� 327,67 mm;
� differential, in which eight-bit "bytes" are used to express values in the range � 1,26 mm to� 1,27 mm;
� incremental, in which four-bits "nibbles" are used to express values in the range � 0,07 mm to� 0,07 mm.
The first radius in a tracing is always expressed using the absolute data type. Radii subsequent to the first may be
expressed as any of the three forms. Special values are reserved for each of the three types, which are inserted
into the data stream to indicate that subsequent radii will be expressed in a different data type. These are shown in
Table 4.
Table 4 — Packed binary type-shifting flag characters
Hexadecimal
Data type Decimal value Action Label
value
Word 0�8000 � 32768 Shift from absolute to differential form AD
Byte 0�80 � 128 Shift from differential to incremental form DI
Byte 0�81 � 127 Shift from differential to absolute form DA
Nibble Shift from incremental to differential form ID
0�8 � 8
Trace radii can always be expressed by the absolute data type, in which case the magnitude of the radius is simply
encoded in a sixteen-bit word value in units of 0,01 mm, thus requiring sixteen bits per radius. Were this done for
an entire record, the format would be indistinguishable from the binary absolute format.
NOTE The following examples use the sequences of radii: 25.40, 25.62, 25.97, 27.20, 28.00, 28.30, 28.35, 28.40, 28.43.
EXAMPLE Radii expressed in absolute form.
Ra
...
NORME ISO
INTERNATIONALE 16284
Première édition
2001-06-01
Optique ophtalmique — Échange
d'informations pour l'équipement d'optique
ophtalmique
Ophthalmic optics — Information interchange for ophthalmic optical
equipment
Numéro de référence
©
ISO 2001
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifiéà moins que l'ordinateur employéà cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la créationduprésent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-aprèsouducomité membre de l’ISO dans le pays du demandeur.
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.ch
Web www.iso.ch
Imprimé en Suisse
ii © ISO 2001 – Tous droits réservés
Sommaire Page
Avant-propos.iv
Introduction.v
1 Domaine d'application.1
2Référence normative .1
3Termesetdéfinitions.1
3.1 Termes généraux .1
3.2 Caractères spéciaux.2
3.3 Types de données.2
3.4 Messages.3
3.5 Enregistrements.4
3.6 Sessions .4
3.7 Temporisation .5
4Généralités .5
5 Exigences .6
5.1 Enregistrements.6
5.2 Enregistrements de points de référence.8
5.3 Enregistrements de générateur.9
5.4 Enregistrements de lecture .11
5.5 Paquets .17
6 Sessions .20
6.1 Généralités .20
6.2 Sessions d'initialisation.21
6.3 Sessions de téléchargement vers l'amont (upload).29
6.4 Sessions de téléchargement vers l'aval (download) .31
7 Autres exigences .32
7.1 Paramètres de communication RS-232 .32
7.2 Messages opérateur .32
Annexe A (normative) Labels d’enregistrement .33
Annexe B (informative) Exemple de format binaire condensé .57
Annexe C (informative) Exemple de calcul de CRC.64
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiéeaux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude aledroit de faire partie ducomité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 3.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
L’attention est appelée sur le fait que certains des éléments de la présente Norme internationale peuvent faire
l’objet de droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable de
ne pas avoir identifié de tels droits de propriété et averti de leur existence.
La Norme internationale ISO 16284 a étéélaboréepar le comité technique ISO/TC 172, Optique et instruments
d'optique, sous-comité SC 7, Optique et instruments ophtalmiques.
L’annexe A constitue un élément normatif de la présente Norme internationale. Les annexes B et C sont données
uniquement à titre d'information.
iv © ISO 2001 – Tous droits réservés
Introduction
La présente Norme internationale est issue d'un besoin ressenti par les fabricants de matériel pour laboratoires
d'optique et par les éditeurs de logiciels utilisés par ce type de laboratoires de simplifier l'interconnexion de leurs
produits.
La présente Norme internationale définie ci-dessous fournit:
� une méthode pour les échanges de données entre machines et systèmes informatiques;
� une méthode permettant aux systèmes informatiques d'initialiser sur les machines les paramètres autoriséspar
les fabricants;
� une méthode permettant aux machines d'initialiser les systèmes informatiques en fonction des informations
que ces derniers sont susceptibles d'utiliser pour différentes tâches;
� une méthode permettant à une machine d'indiquer à un système informatique les informations qu'elle doit
recevoir, et ainsi de définir dynamiquement de nouvelles interfaces;
� un ensemble standard d'enregistrements et de types de périphériques utiliséspourl'échange des informations
convenues.
Ce dernier point nécessite un amendement régulier delaprésente Norme internationale, puisque le besoin en
nouveaux éléments de données est inévitable.
NORME INTERNATIONALE ISO 16284:2001(F)
Optique ophtalmique—Échange d'informations pour l'équipement
d'optique ophtalmique
1 Domaine d'application
La présente Norme internationale établit une méthode permettant aux machines et aux systèmes informatiques
utilisés dans la fabrication de lentilles ophtalmiques d'échanger des informations.
2Référence normative
Le document normatif suivant contient des dispositions qui, par suite de la référence qui y est faite, constituent des
dispositions valables pour la présente Norme internationale. Pour les références datées, les amendements
ultérieurs ou les révisions de ces publications ne s’appliquent pas. Toutefois, les parties prenantes aux accords
fondés sur la présente Norme internationale sont invitées à rechercher la possibilité d'appliquer l'édition la plus
récente du document normatif indiqué ci-après. Pour les références non datées, la dernière édition du document
normatif en référence s’applique. Les membres de l'ISO et de la CEI possèdent le registre des Normes
internationales en vigueur.
ISO 13666:1998, Optique ophtalmique — Verres de lunettes — Vocabulaire.
3 Termes et définitions
Pour les besoins de la présente Norme internationale, les termes et définitions donnés dans l'ISO 13666 ainsi que
les suivants s'appliquent.
3.1 Termes généraux
3.1.1
périphérique
machine ou instrument utilisé dans la fabrication de lentilles ophtalmiques qui communique avec un système
informatique pour envoyer ou recevoir les informations concernant un travail
3.1.2
hôte
système informatique qui fournit des informations à un périphériqueouquienreçoit de celui-ci
3.1.3
travail
commande portant sur des verres ou lentilles ophtalmiques de correction
3.1.4
téléchargement vers l’aval
session de communication dans laquelle le système hôte transmet des données vers le périphérique
3.1.5
téléchargement vers l’amont
session de communication dans laquelle le périphérique transmet des données vers l’hôte
3.2 Caractères spéciaux
3.2.1
séparateur de codes
caractère spécial utilisé pour délimiter les codes dans un enregistrement de périphérique
3.2.2
caractère de position CRC
caractère spécial qui indique l'emplacement de la fin des enregistrements de données et du début de
l’enregistrement CRC facultatif à l'intérieur d'un paquet
3.2.3
caractère de fin
caractère spécial qui indique la fin d'un paquet
3.2.4
séparateur de champs
caractère spécial qui délimite les champs dans un enregistrement
3.2.5
séparateur de labels
caractère spécial qui séparelelabeld’enregistrement du(des) champ(s) dans un enregistrement
3.2.6
indicateur d'enregistrement obligatoire
caractère spécial qui marque certains enregistrements comme obligatoires
3.2.7
caractère de début
caractère spécial qui indique le début d'un paquet
3.2.8
séparateur d'enregistrements
caractère spécial qui délimite les enregistrements
3.2.9
caractères réservés
jeudecaractères réservés à des fonctions particulières
3.2.10
indicateur de données inconnues
caractère spécial qui indique que l'hôte ne reconnaît pas les données nécessaires pour un champ donné
3.2.11
caractère ACK
caractère spécial indiquant la réussite de la transmission d’un paquet
3.2.12
caractère NAK
caractère spécial indiquant l’échec de la transmission d’un paquet
3.3 Types de données
3.3.1
données limitées
données texte dont la longueur est limitée
2 © ISO 2001 – Tous droits réservés
3.3.2
données littérales
données texte spécifiées dans la présente Norme internationale et dont la longueur est limitée
3.3.3
données numériques
données numériques, y compris nombres à virgule flottante et entiers
3.3.4
données texte
chaînes de caractères n'ayant pas de signification prédéfinie
3.3.5
données nombre entier
données représentées sous forme de nombres entiers
3.3.6
données binaires
données présentées sous une forme permettant à un logiciel informatique de les utiliser avec peu ou pas de
traduction
NOTE Elles nécessitent une manipulation spéciale afin d’éviter l’introduction de caractères de contrôle.
3.4 Messages
3.4.1
message
flux de données structuré,transmis d'unhôte à un périphérique ou d'un périphérique à un hôte
3.4.2
message de confirmation
message envoyé par le destinataire d'un paquet composé d'un seul caractère qui indique que la transmission a
réussi
3.4.3
accusé de réception positif
message composé d'un seul caractère qui indique à l'émetteur d'un message que celui-ci a bien été reçu
3.4.4
accusé de réception négatif
message composé d'un seul caractère qui indique à l'émetteur d'un message que celui-ci n'a pas été correctement
reçu
3.4.5
paquet
message structuré composé d'un caractère de départ, d'une série d'enregistrements et d'un caractère de fin
3.4.5.1
paquet de données
paquet envoyéà un hôte par un périphérique ou à un périphérique par un hôte contenant l'information demandée
3.4.5.2
paquet de demande
paquet envoyéà un hôte par un périphérique pour lancer une session
3.4.5.3
paquet de réponse
paquet qui contient des informations d'état
3.5 Enregistrements
3.5.1
enregistrement
flux structuré de caractères qui comprend un label d'enregistrement, un séparateur de labels, zéro ou plusieurs
champs de données espacés par des séparateurs, et un séparateur d'enregistrements final
3.5.2
champ de données
élément de données unique à l'intérieur d'un enregistrement
3.5.3
label d'enregistrement
moyen d'identification des données contenues dans un enregistrement, et dont la taille est limitée à 8 caractères
qui ne comportent pas de caractères spéciaux définisdanslaprésente Norme internationale
3.5.4
enregistrement ASCII
enregistrement composé de caractères ASCII et conforme aux structures définies dans la présente Norme
internationale
3.5.5
enregistrement binaire
enregistrement composé d'octets codésensystème binaire
3.5.6
enregistrement binoculaire
enregistrement comportant deux champs, l’un concernant une lentille ou un œil côté droit, l’autre pour une lentille
ou un œil côté gauche, l’ordre de ces champs étant côté droit en premier, côté gauche ensuite
3.5.7
enregistrement CRC
enregistrement en fin de chaque paquet comportant une valeur de contrôle cyclique par redondance CRC-16
CCITT calculée à partir des caractères transmis
3.5.8
enregistrement de périphérique
enregistrement comportant les éléments de données propres à un travail, transmis entre les périphériques et les
hôtes
3.5.9
enregistrement d'interface
enregistrement qui supporte le fonctionnement de l'interface hôte-périphérique et ne comporte pas de données
spécifiques à un travail
3.6 Sessions
3.6.1
session
séquence de messages transmis entre un périphérique et un hôte qui permet d'échanger des informations relatives
à une instruction ou à une tâche particulière
3.6.2
session d'initialisation
session spécialisée qui permet aux périphériques de fournir des informations aux hôtestellesque le modèle de la
machine, la version du logiciel et l'identification de l'opérateur, et qui évite de repréciser ces informations à chaque
demande
4 © ISO 2001 – Tous droits réservés
3.6.2.1
initialisation auto-format
session d'initialisation qui permet aux périphériques de définir les jeux d'enregistrements de périphérique devant
être demandésaux hôtes
3.6.2.2
initialisation prédéfinie
session d'initialisation qui permet aux périphériques de transmettre aux hôtes des jeux de données d'identification
3.6.3
session de téléchargement vers l'aval (download)
session au cours de laquelle les informations sont transmises d'un hôte à un périphérique
3.6.4
session de téléchargement vers l'amont (upload)
session au cours de laquelle les informations sont transmises d'un périphérique à un hôte
3.6.5
session INFO
paquet de demande de téléchargement vers l'amont qui contient des informations sur l'état d'un travail. Il est utilisé
pour indiquer la fin d’un travail exécuté par un périphérique
3.6.6
session MNT
paquet de demande de téléchargement vers l'amont qui contient des informations sur les périphériques spécifiques
à un fournisseur
3.7 Temporisation
3.7.1
temporisation
valeur numérique qui représente la période pendant laquelle un hôte ou un périphérique attend des données et à
l'expiration de laquelle il considère qu'elles ne leur parviendront pas
3.7.1.1
temporisation de confirmation
temporisation qui s'applique à la réception d'un message de confirmation
3.7.1.2
temporisation intercaractères
temporisation qui s'applique à l'intervalle entre des caractères consécutifs dans un flux de données
3.7.1.3
temporisation de paquet
temporisation qui s'applique à la réception d'un paquet
4Généralités
La stratégie utilisée dans la présente Norme internationale pour l'échange de données entre périphériques et hôtes
peut être définie comme suit.
Une machine utilisée dans la fabrication de lentilles ophtalmiques (un périphérique) envoie une demande à un
système informatique (un hôte) concernant la réalisation de l'une des actions suivantes:
� initialiser les informations afin d’identifier le périphérique, les versions logicielles, les numéros de modèle, etc.;
� télécharger vers l'hôte des informations que celui-ci doit enregistrer et/ou utiliser pour le traitement de
commandes de verres ophtalmiques;
� télécharger à partir de l'hôte les informations nécessaires au périphérique pour la réalisation de ses tâches.
La communication peut être initialisée de deux façons.Soitlepériphérique procède à une session d'initialisation,
soit l'hôte oblige le périphérique à le faire en refusant une demande normale et en demandant une initialisation en
émettant un code d'erreur spécial. Pour les demandes de téléchargement vers l'amont, l'hôte accuse réception de
la demande et le périphérique envoie ses données, dont l'hôte accuse réception. L'hôte répond aux demandes de
téléchargement vers l'aval en envoyant les données demandées.
Les paquets de données de longueur variable qui constituent cet échange sont composésd’une série
d'enregistrements contenant chacun des données et un label identifiant ces dernières. La présente Norme
internationale définit un jeu de labels ainsi que les données qui leur sont associées. Ce jeu sera développé dans
l’avenir selon les besoins.
Un échange de paquets intervenant dans un travail unique est appelé session. La structure de ces sessions et les
paquets d'enregistrement les composant font l'objet de la présente Norme internationale.
Bien que la présente Norme internationale soit conçue pour êtremiseen œuvre sur des liaisons série RS-232
point à point, elle peut être appliquée à d'autres plates-formes matérielles. Des spécifications peuvent alors y être
ajoutées afin d'optimiser l'interconnectabilité entre les différents hôtes et périphériques.
5 Exigences
NOTE Dans lesexemplesdela présente Norme internationale, pour des raisons de lisibilité,les SÉPARATEURS
D'ENREGISTREMENTS et les ENREGISTREMENTS CRC ne sont pas toujours indiqués et les CARACTÈRESDEDÉBUT
peuvent être placés sur une ligne séparée. Les remarques sont présentées sous forme d'enregistrements REM. Les
commentaires apparaissent entre crochets ( [ … ] ) et ne font pas partie du flux de données. Les trois points ( «…» )
représentent des données du même type que celles qui les précèdent et leur succèdent. Pour une meilleure lisibilité,des
ESPACES ont été rajoutées autour des séparateurs et des enregistrements de champs; dans la pratique, il est préférabledene
pas les laisser dans les paquets car elles diminuent inutilement l'efficacité de l'expression. Dans les descriptions ci-dessous les
termes DEMANDE, RÉPONSE et DONNÉES s'appliquent aux paquets.
5.1 Enregistrements
5.1.1 Enregistrements d'interface
La présente Norme internationale définit un jeu d'enregistrements d'interface. Ces enregistrements contiennent des
informations utilisées par l’hôte et le périphérique pour communiquer. Ils ne contiennent pas de données
spécifiques à un travail. Ils sont énumérésenA.2.
5.1.2 Enregistrements de périphérique
La présente Norme internationale définit un jeu d'enregistrements de périphérique qui identifie les éléments de
données dont peut avoir besoin l’un des périphériques susceptibles de participer à la réalisation d'un travail. Ces
enregistrements sont énumérésenA.1.
5.1.3 Types de périphérique prédéfinis
La présente Norme internationale distingue également des sous-ensembles d'enregistrements de périphérique
estimés appropriés à des types de périphérique spécifiques. Ils sont énumérésenA.3.
5.1.4 Enregistrements obligatoires
Les enregistrements obligatoires sont désignés comme tels dans leur définition. Les enregistrements qui ne portent
pas cette mention sont considérés comme optionnels.
6 © ISO 2001 – Tous droits réservés
5.1.5 Enregistrements avec valeurs inconnues
Lorsqu'il est demandéà l'hôte d'envoyer un enregistrement obligatoire pour lequel il n'a pas d'information, il envoie
celui-ci avec un point d'interrogation « ? » dans tous les champs de données qui lui sont inconnus pour indiquer
que l'information n'est pas disponible. De tels enregistrements doivent être mis en forme conformément aux règles
sur les enregistrements binoculaires.
5.1.6 Enregistrements ignorés
Lorsqu'un hôte reçoit un enregistrement avec un label qu’il ne reconnaît pas, il ignore cet enregistrement.
5.1.7 Enregistrements expérimentaux
Lorsqu'un fournisseur de machines souhaite soumettre à l’essai de nouveaux enregistrements avant de demander
leur incorporation à la présente Norme internationale, il doit utiliser pour ces enregistrements des labels
commençant par le caractère de soulignement (caractère ASCII « _ », valeur décimale 95). Les labels
d'enregistrement ont une longueur limitée à 8 caractères, et ils ne doivent comporter aucun des caractères
spéciaux définis dans la présente Norme internationale.
5.1.8 Caractères réservés
5.1.8.1 Les caractères de contrôle et les caractères supplémentaires spécifiés ne doivent pas apparaître dans
le flux des données transmises, sauf indication contraire. Le jeu des caractères réservésest présenté dans le
Tableau 1.
5.1.8.2 Les caractères réservés comme, par exemple, les séparateurs de champs et d'enregistrements,
doivent apparaître dans les enregistrements ASCII uniquement pour effectuer la fonction qui leur a été attribuée.
Les caractères réservésrépondant à la définition de données texte peuvent également apparaître dans les champs
de texte, lesquels sont délimités par des guillemets.
5.1.8.3 Lorsqu'un caractère réservé avec une valeur décimale inférieure à 32 apparaît dans un enregistrement
binaire, il convient d’envoyer deux caractères à sa place. Le premier doit êtreuncaractère ESC, suivi par le
caractère original avec son bit de poids fort défini. Cela revient à appliquer l'opérateur OR à ce caractère avec le
décimal 128, hexadécimal 0�80. Le destinataire, à la réception d'un caractère ESC, doit supprimer celui-ci et
effacer le bit de poids fort du caractère qui suit. La valeur CRC, s'il y en a une, doit être déterminée aprèsajout du
caractère ESC à ces caractères réservés pour que le destinataire n'ait pas à traiter les paquets avant la validation
du CRC d'un paquet reçu.
NOTE En d'autres termes, l'émetteur code les caractères de contrôle avant de calculer le CRC, et le destinataire calcule le
CRC avant de les décoder.
EXEMPLE Flux d'octets (enregistrement de lecture court au format absolu binaire) avant et après ajout du caractère ESC
comme précisé ci-dessus.
Avant:
R=175 9 23 10 45 10 223 9 90 9 205 8 89 8 252 7 183 7 143 7
130 7147 7197 724813681891679391085101910
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
Après:
R=175 9 23 27 138 45 27 138 223 9 90 9 205 8 89 8 252 7 183 7 143 7
130 71477197 72481368189167939 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.8.4 Les données limitées sont une chaîne de caractères ASCII compris dans la plage des valeurs
décimales 32 à 127. Leur longueur est limitée à 12 caractères. Les données limitées doivent être entourées de
guillemets (décimal ASCII 34). En revanche, elles ne peuvent pas contenir de guillemets.
5.1.8.5 Les données texte sont une chaîne de caractères ASCII compris dans la plage des valeurs décimales
32 à 127 dont la signification n'est pas prédéfinie. Leur longueur est de 80 caractères maximum. Les données texte
doivent être entre guillemets (décimal ASCII 34). Elles ne peuvent pas contenir de guillemets.
5.1.8.6 Les données littérales sont une chaîne de caractères dont la signification dépend du type
d'enregistrement (comme spécifié dans ce document). Leur longueur est limitée à 12 caractères, sauf indication
contraire dans la définition de l'enregistrement. Elles ne peuvent contenir aucun des caractères spéciaux définis
par l'interface. Les guillemets ne sont pas nécessaires.
Tableau 1 — Caractères réservés
Valeur Valeur Touche de
Caractère Signification
hexadécimale décimale commande
FS 0�1C 28 ^\ Début du message
GS 0�1D 29 ^] Fin du message
DC1 0�11 17 ^Q Réservé (XOFF)
DC3 0�13 19 ^S Réservé (XON)
ACK 0�06 06 ^F Accusé de réception positif
NAK 0�15 21 ^U Accusé de réception négatif
ESC 0�1B 27 ^[ Échappement
RS 0�1E 30 ^^ Séparateur CRC
SUB 0�1A 26 ^Z Marque de fin de fichier DOS
CR 0�0D 13 ^M Séparateur d'enregistrements
LF 0�0A 10 ^J Séparateur d'enregistrements
;0�3B 59 ; Séparateur de champs
=0�3D 61 = Séparateur de labels
@0�40 64 @ Réservé
,0�2C 44 , Séparateur de codes
*0�2A 42 * Indicateur d'enregistrement obligatoire
?0�3F 63 ? Indicateur de données inconnues
5.2 Enregistrements de points de référence
5.2.1 Ces enregistrements sont définis pour indiquer les distances horizontales et verticales entre deux points de
référence ou une action relative à un point de référence qu'une machine doit exécuter. Le système de
dénomination ci-après permet de comprendre les différents enregistrements de références cités dans la présente
Norme internationale et peut être facilement appliquéà de nouveaux cas.
5.2.2 Les deux premières lettres du label d'enregistrement représentent le premier point de référence, les
troisième et quatrième lettres, le second point de référence et les deux dernières lettres la direction « IN »
(horizontale) ou « UP » (verticale). Ces valeurs identifient la position du second point par rapport au premier.
5.2.3 Une valeur IN positive signifie que le second point de référencesetrouvecôté nasal par rapport au
premier.
8 © ISO 2001 – Tous droits réservés
5.2.4 Une valeur IN négative signifie que le second point de référencese trouvecôté temporal par rapport au
premier.
5.2.5 Une valeur UP positive indique que le second point de référence se trouve au-dessus du premier.
5.2.6 Une valeur UP négative indique que le second point de référence se trouve au-dessous du premier.
Tableau 2 — Identificateurs de point de référence
Identificateur Point de référence
BC Centre de verre brut
FB Bloc de débordage
FC Centre de monture
OC Centre optique / Point de référenceduprisme
SB Bloc de surfaçage
SG Segment
Tableau 3 — Enregistrements de points de référence
Label Signification
FBFCIN, FBFCUP Bloc de débordage – centre de monture
FBSGIN, FBSGUP Bloc de débordage – segment
FBOCIN, FBOCUP Bloc de débordage – point de référence du prisme (centre optique)
SBBCIN, SBBCUP Bloc de surfaçage – centre de verre brut
BCSGIN, BCSGUP Centre de verre brut – segment
BCOCIN, BCOCUP Centre de verre brut – centre optique
SBSGIN, SBSGUP Bloc de surfaçage – segment
SBOCIN, SBOCUP Bloc de surfaçage – point de référence du prisme
SBFCIN, SBFCUP Bloc de surfaçage – centre de monture
SGOCIN/SGOCUP Segment – centre optique
FCSGIN/FCSGUP Centre de monture – segment (identique à la hauteur ou au décalage
vertical du segment)
FCOCIN/FCOCUP Centre de monture – centre optique (identique à la hauteur ou au
décalage vertical du centre optique)
5.3 Enregistrements de générateur
5.3.1 L'interface d’un générateur de surface comprend plusieurs enregistrements qui indiquent les ajustements à
effectuer sur les paramètres du générateur. La présente Norme internationale décrivant le jeu complet de données
(« paquet prédéfini ») qui doit être envoyéà un générateur « inconnu », il est important de clarifier certains rapports
existant entre ces enregistrements, notamment en ce qui concerne les champs de « compensation ».
La position d'une lentille dans un générateur peut être déterminée par les champs RNGH, RNGD, SAGRD et
SAGBD (respectivement hauteur de gland de surfaçage, diamètredegland, flèche du verre au niveau du diamètre
du gland et flèche du verre au niveau du diamètre du verre brut). Certains générateurs, en particulier ceux dont les
composants sont exclusivement mécaniques, peuvent déterminer une valeur pour certains des enregistrements
ci-dessus, mais s’avérer incapables d'apporter les ajustements nécessaires en cas de discordance. Les champs de
compensation suivants fournissent les données nécessaires pour réaliser ces ajustements.
5.3.2 BLKCMP représente la modification devant être apportée au paramètre d'épaisseur du générateur en
raison d’une discordance entre la courbure d'un bloc dont la surface de contact avec la lentille est courbe et la
courbure de la lentille posée sur ce bloc. Le champ BLKB contient la courbure de la surface du bloc en contact
avec la lentille, et le champ BLKD le diamètredubloc.
5.3.3 Lorsque la surface de contact des blocs utilisés pour un travail n'est pas courbe, le champ BLKB n'est pas
nécessaire. S'il est envoyé dans un tel cas, sa valeur doit être équivalente à IFRNT.
5.3.4 RNGCMP représente la modification devant être apportée au paramètre d'épaisseur du générateur en
raison d’une discordance entre la valeur de hauteur et/ou de diamètre du gland connue par l’hôte et celle
déterminéepar legénérateur.
5.3.5 FINCMP indique la valeur d’épaisseur à ajouter au paramètre du générateur pour tenir compte de la
matière retirée lors du doucissage (lissage) et du polissage.
5.3.6 THKCMP peut être utilisé pour les compensations d'épaisseur non prises en charge par les
enregistrements définisdanslaprésente Norme internationale.
NOTE Les champs de compensation d'épaisseur ci-dessus s'appliquent de la même façon à GTHK et à OTHK.
5.3.7 EECMP indique la quantité de dioptries à ajouter aux valeurs GCROS et GCROSX lorsqu'une
compensation est nécessaire en raison d’une erreur elliptique.
5.3.8 Un hôte peut garder le contrôle total des paramètres d'un générateur en incluant dans les enregistrements
de paramètres de base toutes les valeurs de compensation qu'il estime nécessaires à une machine donnéeet en
envoyant des valeurs zéro dans les enregistrements de compensation. Par exemple, l’addition de GCROS et
EECMP, l’envoi de GCROS comme résultat et l’envoi de EECMP avec des valeurs égales à zéro.
5.3.9 Les valeurs zéro dans les enregistrements de compensation indiquent que l'hôte ordonne à la machine de
ne pas appliquer les compensations qu’elle est susceptible d’être paramétrée pour effectuer.
5.3.10 L'ABSENCE de champs de compensation signifie que le générateur doit appliquer les compensations
qu'il est paramétré pour effectuer.
5.3.11 Prisme/décentrage: les champs GPRVM et GPRVA représentent la grandeur et la direction du prisme à
générer. Ces valeurs doivent comprendre toutes les composantes prismatiques possibles, y compris le prisme de
prescription, le prisme d’allègement et le prisme de décentrage. Les champs SBOCIN et SBOCUP expriment les
distances latérale et verticale vectorielles selon lesquelles le centre d’usinage doit être décalé par rapport au centre
du bloc de surfaçage. Pour que ces deux valeurs puissent être exprimées dans un même paquet, comme cela est
souhaitable dans le cas d'une demande GEN « générique », les enregistrements RPRVM et RPRVA sont définis.
Ceux-ci représentent le prisme à usiner à l’exception du décentrage exprimé dans SBOCIN/SBOCUP. De plus,
lorsque le décentrage est exprimé directement (par SBOCIN/SBOCUP), la valeur OTHK doit être présente. Les
règles suivantes décrivent la façon dont ces champs doivent être associés:
5.3.11.1 Lorsque le décentrage doit être généré sous forme de prisme, les champs suivants sont utilisés
ensemble: GPRVM, GPRVA et GTHK.
5.3.11.2 Lorsque le décentrage doit être généré directement, les champs suivants sont utilisés ensemble:
RPRVM, RPRVA, SBOCIN, SBOCUP et OTHK.
5.3.11.3 La méthode décriteen5.3.11.1, quiexprime le décentrage sous forme de prisme, est la plus
universelle pour exprimer un décentrage à usiner, et tous les générateurs et hôtes prennent donc en charge les
enregistrements décrits ici. Les enregistrements décrits dans la section 5.3.11.2, qui exprime le décentrage sous
forme vectorielle, doivent être ajoutés à ceux de la section 5.3.11.1. Les générateurs qui ne supportent pas la
méthode vectorielle peuvent ignorer en toute sécurité leschampsvectoriels.
10 © ISO 2001 – Tous droits réservés
5.3.12 Épaisseur du pad: la présence de l'enregistrement PADTHK indique que les courbes LAP découpées par
un générateur doivent être compensées en fonction de l'épaisseur du pad. Aucune compensation ne doit être
réalisée pour les courbes de lentille exprimées dans GBASE/GCROS ou GBASEX/GCROSX. Il incombe à l'hôte
de déterminer les compensations qui doivent être appliquées aux courbes du générateur, celles-ci pouvant être
rendues nécessaires par l'utilisation de polissoirs non compensés par rapport à l'épaisseur du pad, ou par le
souhait de doucir les lentilles du bord au centre.
5.3.13 Signe des courbes: les courbes concaves sont exprimées par des nombres négatifs, et les courbes
convexes par des nombres positifs. Cela signifie que, pour les générateurs qui découpent des polissoirs, les
courbes de lentille et les courbes de polissoir doivent avoir des signes opposés.
5.4 Enregistrements de lecture
5.4.1 Expression des données de lecture
L'expression des données de lecture commence avec l'enregistrement TRCFMT, qui spécifie le format dans lequel
la lecture doit être exprimée, le nombre de points à transmettre, le mode radial (rayons équiangles ou non),
l'orientation de la lecture et l’objet de la lecture.
5.4.2 Données radiales
Les données radiales sont contenues dans les enregistrements « R » et les données Z dans les enregistrements
« Z ». Les données angulaires des données radiales sont contenues dans les enregistrements « A » et celles des
données Z dans les enregistrements ZA. En format ASCII, tous les enregistrements respectent la limite de 80
caractères par ligne, et par conséquent il est possible (et même probable) qu’une lecture contienne plusieurs
enregistrements R, A, Z, et ZA. Pour les données binaires, la limite de caractères ne s'applique pas et il n'existe
qu'un enregistrement R, A, Z et ZA. Les données radiales et Z sont exprimées en centièmes de degré avec un
point décimal implicite.
EXEMPLE Données radiales:
a) Format ASCII
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) Format binaire
TRCFMT=2;400;E;R;F
R=
5.4.3 Angles non égaux
Lorsque des angles non égaux sont spécifiés dans l'enregistrement TRCFMT, la présence de données angulaires
est nécessaire. Elles doivent apparaître immédiatement après les données radiales correspondantes. Les données
angulaires sont contenues dans un ou plusieurs enregistrements « A » et doivent être exprimées dans le même
format que celui des données radiales auxquelles elles correspondent. Les données angulaires sont exprimées en
centièmes de degré avec un point décimal implicite et elles doivent être comprises dans la plage de 0 à 35999.
NOTE Les données angulaires peuvent également suivre des données Z si des angles non égaux sont spécifiéspour ces
dernières.
5.4.4 ZFMT
L'enregistrement du format des données Z, ZFMT, a exactement la même définition que l'enregistrement TRCFMT.
Les même règles s'appliquent pour les données angulaires concernant les données Z et les données radiales.
5.4.5 Enregistrements « R »
Les enregistrements « R » doivent apparaître immédiatement après l'enregistrement TRCFMT. Tous les
enregistrements « R » concernant une lecture (c’est-à-dire, un seul côté, lorsqu'il y en a deux) apparaissent
ensemble. Chaque côté fait l’objet d’un enregistrement TRCFMT.
5.4.6 Enregistrements « Z »
Les enregistrements « Z » doivent apparaître immédiatement après l'enregistrement ZFMT. Tous les
enregistrements « Z » concernant une lecture (c’est-à-dire, un seul côté, lorsqu'il y en a deux) apparaissent
ensemble. Chaque côté fait l’objet d’un enregistrement ZFMT.
5.4.7 Enregistrements « A » ou ZA
Les enregistrements « A » ou ZA, lorsqu'ils sont présents, doivent apparaître immédiatement aprèsles
enregistrements « R » ou « Z » correspondants. Les enregistrements ZFMT et « Z » doivent apparaître
immédiatement après les enregistrements TRCFMT et « R » correspondants.
EXEMPLE Jeu de données de lecture (abrégé) pour les deux yeux illustrant l’ordre des enregistrements.
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
…
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 Lectures de monture
Les lectures de monture doivent être centrées géométriquement lorsqu'elles sont présentées à l'hôte. Celui-ci peut
décentrer la forme afin de produire un certain effet sur un périphérique.
12 © ISO 2001 – Tous droits réservés
5.4.9 Données de lecture
Les données de lecture doivent être exprimées de façon à ce que le premier rayon se trouve au degré zéro (3 h
sur une échelle polaire standard) et doivent évoluer dans le sens contraire des aiguilles d'une montre. Lorsque des
données angulaires sont fournies, le rayon de départ doit être celui situé sur le premier méridien disponible
supérieur ou égal à zéro.
5.4.10 Orientation oculaire
5.4.10.1 L'orientation oculaire, droite ou gauche, doit être considéréedelamanière dont un réfractionniste
observe un porteur de lunettes: les données orientées œil droit doivent commencer côté nasal, et les données
orientées œil gauche côté temporal.
5.4.10.2 L'orientation oculaire peut être déterminéeaucours del'initialisationou être spécifiée dans le paquet
de demande du lecteur.
5.4.10.3 Lorsque l'œil R (droit) est spécifié,lepériphérique veut envoyer ou recevoir un jeu unique de données
de lecture orientées œil droit.
5.4.10.4 Lorsque l'œil L (gauche) est spécifié,lepériphérique veut envoyer ou recevoir un jeu unique de
données de lecture orientées œil gauche.
5.4.10.5 Lorsque B (les deux yeux) est spécifié,lepériphérique veut envoyer ou recevoir les deux jeux (droit et
gauche) des données de lecture, chacun dans son orientation respective.
5.4.11 Orientation oculaire au cours de la transmission de la lecture
5.4.11.1 Lorsque l'œil R (droit) est spécifié dans les enregistrements TRCFMT ou ZFMT, la lecture a
l'orientation œil DROIT.
5.4.11.2 Lorsque l'œil L (gauche) est spécifié dans les enregistrements TRCFMT ou ZFMT, la lecture a
l'orientation œil GAUCHE.
5.4.11.3 Bne doitpas être spécifié dans les paquets de données, mais uniquement dans les paquets de
demande ou d'initialisation. Les paquets de données dans lesquels les deux côtés sont présents doivent
comprendre deux enregistrements TRCFMT, un pour chaque côté, avec leur label respectif.
5.4.12 Hôtes et périphériques
Les hôtes et périphériques doivent pouvoir prendre en charge la réception de toute orientation des données de
lecture sans générer d'erreur.
5.4.13 Exemple de format de lecture
Dans une expression de données Z, le plus petit nombre du jeu de données doit être positif et doit représenter le
point le plus éloigné vers l'avant de la monture ou lentille. Les distances entre ce point et chacun des autres points
du jeu doivent avoir des valeurs positives espacées par incréments de0,01mm.
NOTE 1 Il est fortement recommandé d'assurer que les périphériques effectuent une représentation homogène des
données. En effet, bien que cela ne soit pas expressément interdit, la représentation des données radiales dans une orientation
et des données Z dans une autre peut constituer une violation des hypothèses non garanties par les programmeurs des
ordinateurs hôtes et provoquer l’échec.
NOTE 2 La brève lecture suivante, qui comprend 40 rayons, sera utilisée dans les exemples ci-dessous. Elle n'a pas de
mise en forme particulière: il s'agit simplement de la liste des valeurs radiales utilisées dans les exemples qui suivent.
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.4.14 Format absolu ASCII
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...