1、AMERICAN NATIONAL STANDARDOLAANSI Z80.26-1996 (R2003)Editorial updateSeptember 21, 1998for Ophthalmics Data Processing and Information Interchange for Ophthalmic InstrumentsANSIZ80.26-1996 (R2003)Editorial updateSeptember 21, 1998American National Standardfor Ophthalmics Data Processingand Informati
2、on Interchangefor Ophthalmic InstrumentsSecretariatOptical Laboratories AssociationApproved September 27, 1996American National Standards Institute, Inc.Approval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval
3、havebeen met by the standards developer.Consensus is established when, in the judgement of the ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected interests. Substantial agreement means much more thana simple majority, but not necessarily unanimit
4、y. Consensus requires that allviews and objections be considered, and that a concerted effort be madetowards their resolution.The use of American National Standards is completely voluntary; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manu
5、facturing, marketing, purchasing, or usingproducts, processes, or procedures not conforming to the standards.The American National Standards Institute does not develop standards andwill in no circumstances give an interpretation of any American NationalStandard. Moreover, no person shall have the ri
6、ght or authority to issue aninterpretation of an American National Standard in the name of the AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American Nation
7、al Standard may be revised orwithdrawn at any time. The procedures of the American National StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard. Purchasers of American National Standards mayreceive current information on all standards by calling
8、 or writing the AmericanNational Standards Institute.American National StandardPublished byOptical Laboratories AssociationP. O. Box 2000Merrifield, VA 22116-2000Copyright 1998 by Optical Laboratories AssociationAll rights reserved.No part of this publication may be reproduced in anyform, in an elec
9、tronic retrieval system or otherwise,without prior written permission of the publisher.Printed in the United States of AmericaDeveloped byThe Accredited Committee Z80 for Ophthalmic Standards -Optical Laboratories AssociationZ80 SecretariatP. O. Box 2000Merrifield, VA 22116-2000iContentsPageForeword
10、 ii1 Scope and purpose 12 Normative references . 13 Definitions, acronyms, and abbreviations. 24 Requirements . 3Tables1 Error Message Codes. 212 Standard Response Codes 223 Identifiers for Instrument variables . 224 Identifiers for Ophthalmic variables 235 Instrument type identification 25AnnexA Ca
11、pability transaction Message definitions 26iiForeword (This foreword is not part of American National Standard Z80.26-1996 (R2003).)An Instrument that conforms to this standard will, at minimum, be able to identify itselfto a Host computer system, providing the Instrument type, model, manufacturer,
12、andsoftware revision level. It provides the capability to look up, by standard name, thedata elements that are available to the Host computer system during Instrument op-eration and allows read and/or write access to the Data Elements. It defines a consis-tent set of data collection and specificatio
13、n methods that are applicable across abroad range of Ophthalmic Instruments. The current standard assumes that no In-strument or Host addressing is required.More flexible and sophisticated Instruments might contain a number of predefined re-ports which could be used to read the Instrument Data Eleme
14、nts in logical groups,and could have the reports generated automatically whenever the Instrument detect-ed the occurrence of some event. This type of Instrument could allow the Host com-puter system to define reports in order to customize the data collection. It could allowthose reports to be connec
15、ted to any of the events that the Instrument is able to rec-ognize.Instruments may also provide a manufacturer-defined suite of Instrument specific ca-pabilities that are available to the Host computer system. By careful design of this ca-pability suite, the manufacturer can provide the desired leve
16、l of remote controlcapability for the Instrument.This allows a minimally conforming Instrument to be produced with a minimum soft-ware burden, while allowing much more complex, flexible and interesting interfacesto be designed within the same communications framework.This document contains one annex
17、 which is normative and is considered part of thestandard.Suggestions for improvement of this standard will be welcome. They should be sent tothe Optical Laboratories Association, P.O. Box 2000, Merrifield, VA 22116-2000, USA.This standard was processed and approved for submittal to ANSI by the Accr
18、editedStandards Committee on Ophthalmics, Z80. Committee approval of this standarddoes not necessarily imply that all committee members voted for its approval. At thetime it approved this standard, the Z80 Committee had the following members:Thomas C. White, M.D., ChairF. Dow Smith, Ph.D., Vice Chai
19、rRobert Rosenberg, O.D., SecretaryOrganization Represented Name of RepresentativeAmerican Academy of Ophthalmology . Thomas C. WhiteEdmund Thall (Alt.)American Academy of Optometry. David M. LoshinAmerican Ceramic Society . John R. HansenJackson S. Stroud (Alt.)Herbert Hoover (Alt.)American Optometr
20、ic Association Robert RosenbergWilliam “Joe” Benjamin (Alt.)Donald Pitts (Alt.)Gregory L. Stephens (Alt.)American Society of Cataract Data Bits: 8; Parity: None; Stop Bits: 1. Instruments which allow for Serial Port Parameter negotiation shall implement the optional Read Serial Parameters and Write
21、Serial Parameters capabilities. The Serial Port Parameter negotiation scheme is intended to allow the Host to select and use the highest possible transfer rate that both parties can sup-port. See 4.11, Serial Port Parameter negotiation. All conforming Instruments shall have a controlling microproces
22、sor and Communications interface. The Instrument should have enough CPU bandwidth to implement the Communications specification in addi-tion to performing its normal test and Measurement Functions. ANSI Z80.26-1996 (R2003) 4 Compliant Instruments shall implement some form of interval timing Capabili
23、ty, with timing resolution of at least one second. Manufacturers shall supply adequate documentation for the Data Elements and Methods that their In-struments support. Transactions may be initiated by either the Host or the Instrument. The initiating party sends a Function Message. The transaction p
24、arty that received the Function Message (either the Host or the Instrument) processes it appropriately and returns a Response Message. 4.2 Transaction processing details Every transaction shall have a Function Message and a Response Message, regardless of whether the Host computer or the Instrument
25、initiates the transaction. Two forms of Response Messages are defined. The first is the Error Message. This type of Response shall be generated whenever the receiver of the Function Message detects an error in the structure or receipt of that Message. The Error Message format is defined below. Some
26、errors of this type are: Unrecognized Function Code; Invalid Message format; Invalid Data format; Message length exceeds receiver Capability. This level of error detection is applied before any Capability-specific processing. If one of the errors de-fined above is detected, execution of the Capabili
27、ty will not be attempted. The second, normal, Response Message informs the transaction initiator of the status of the Capability execution. This type of Message will always contain a Response Code field which indicates the Capabil-ity execution status. Note that the Response Code for each Message ma
28、y indicate that an error occurred during the processing of the Capability. This level of error detection is independent of the level which is described above, and can only occur if no errors were detected in the structure or receipt of the Message. Each Capability definition in 4.4 and 4.5 defines t
29、he possible Response Codes that it generates. The Re-sponse Code 0 is defined for all Capabilities, and is used to indicate that the Capability was successfully executed as requested. Transactions that execute Methods on the Instrument shall generate a Response within the time-out pe-riod that indic
30、ates whether the Method was started. The Instrument shall inform the Host when the Method is completed, and shall return any results. An example is the case where the Host computer re-quests the Instrument to start an automatic calibration procedure. The Instrument would immediately re-spond, indica
31、ting that it was starting the procedure. When the procedure finished, the Instrument would send a Message indicating that the calibration was complete, possibly with an indication of the results. Transactions are timed by the initiator. If a Response or Error Message is not received within the time-
32、out period, a Communications Fault has occurred. The Communications link is still considered to be estab-lished until a Communications Failure is detected by the Data link layer of the protocol. 4.2.1 Function Message format 4.2.1.1 Message Header Field Each Function Message shall begin with the ASC
33、II character G10FG10, followed by a variable number of ASCII numeric characters that specify the unique Function Code (see annex A, table A.1), followed by a space character. 4.2.1.2 Message Data Fields The remainder of the Function Message is Message-specific. In general, Fields shall be separated
34、by single space characters ANSI Z80.26-1996 (R2003) 5 Any space characters that are part of a Data field shall be enclosed in double quotes (“) A double quote character that is part of a Data field shall be preceded by a backslash character () A backslash character that is part of a Data field shall
35、 be preceded by another backslash character. For example: “I want the file c:tempdirjunk.txt“, said John. would be encoded as: “I want the file c:tempdirjunk.txt“, said John.“ 4.2.1.3 Message Terminator The Message shall terminate with a single carriage return character. 4.2.2 Response Message forma
36、t 4.2.2.1 Message Header Field Each non-error Response Message shall begin with the ASCII character G10RG10, followed by the same ASCII numeric character Function Code (see annex A) that was specified in the Function Message, fol-lowed by a single space character. 4.2.2.2 Response Code The Message h
37、eader shall be followed by a variable length ASCII numeric character string that specifies the Response Code for the specific Function as an unsigned integer. Response Codes shall be Function-specific, with the following limitations: 0 (zero) shall indicate that the Function request was successful;
38、Codes greater than zero shall be used to indicate Function-specific Responses. 4.2.2.3 Message Data Fields The remainder of the Response Message shall be Message-specific. The field separators and special character handling shall be identical to those of the Function Message. 4.2.2.4 Message Termina
39、tor The Message shall terminate with a single carriage return character. 4.2.3 Error Message format 4.2.3.1 Message Header Field Each error Message shall begin with the ASCII character G10EG10, followed by a variable length ASCII nu-meric character string (see table 1) that represents the type of er
40、ror detected, followed by a single space character. 4.2.3.2 Message Data Fields The remainder of the Response Message shall consist of the portion of the Function Message that pre-cedes the error. The Function Message Header shall be included in this information. The Function Mes-sage terminating ca
41、rriage return character shall never be returned in this portion of the Message. 4.2.3.3 Error Message Codes The Message shall terminate with a single carriage return character. 4.2.2.4 Message Terminator Table 2 defines all of the standard Error Message codes. Error codes through decimal value 255 a
42、re re-served for future use. Manufacturers are free to define Instrument-specific Error Message Codes with values greater than 255. ANSI Z80.26-1996 (R2003) 6 4.3 Required Instrument controls 4.3.1 Communications Enabled/Disabled Control 4.3.1.1 Purpose This is an Instrument control or state variabl
43、e that determines whether Communications with external equip-ment are allowed. This should be a non-volatile control within the Instrument. The Instrument shall allow the Instrument operator to change the enabled/disabled state during Instrument operation. The Method used to change the control state
44、 may be via software or hardware that will not conflict with the control state stored for use during Instrument initialization. The Instrument may provide a separate Communications enabled/disabled control for each physical Commu-nications interface. If a single control is provided, then it shall co
45、ntrol all physical interfaces. 4.3.1.2 Requirements If Communications are enabled (due to the stored control state) at the time of Instrument initialization, the In-strument shall attempt to establish Communications with external devices. In general, if there are multiple devices connected to the In
46、strument, it is the Instruments responsibility to determine whether it is acting as the Host or the Instrument on each Communications link. If Communications cannot be established, then the Instrument will periodically try to establish Communica-tions for as long as Communications are enabled. If Co
47、mmunications are enabled, the Instrument shall ac-cept a connection request whenever one is received. If Communications are disabled, the Instrument shall respond to any connection request, but its Response Message shall indicate that Communications are dis-abled on this interface. 4.4 Required capa
48、bilities 4.4.1 Establish Communications 4.4.1.1 Purpose This Capability provides a means of formally establishing Communications following system initialization or any loss of Communications. It notifies the communicating partners that a period of non-Communication ex-isted, and signals them that so
49、me synchronization activity may be required. 4.4.1.2 Requirements Function Code (see annex A): 10 Transaction Initiator: Host or Instrument This Capability shall provide a formal means to establish a Communications link. This is required because it is possible for a loss of Communications to be detected by one party in a conversation but not the other. This Capability shall provide for a logical Communications link between the Host and the Instrument at the Application Layer level of the Communications protocol. It shall have no relation to any lower lay
