              Frye PC Communications Interface Definition    page 1

                          FRYERS - Interface Definition
                                    04/05/06


                                    Overview

        The FRYERS driver is a communications interface program written 
        for the IBM PC or compatible computers. The program allows quick 
        and easy communications with Frye Electronics instrumentation by 
        providing a standardized interface. 

        Computer control of Frye Electronics instruments is performed via 
        an Ethernet, USB or RS232 interface. Ethernet, USB and RS232 are 
        well established standards for computers and other equipment to 
        communicate with other devices. 

        The core Ethernet, USB and RS232 standards are a 'hardware' 
        definition. That is, it defines the physical connections between 
        the machines, it does not define the information that is passed 
        over the hardware connection. Other standards define the 
        information flow. 

        The method of passing information over the connection is called a 
        communication protocol.  Protocols are defined in layers. The 
        layered approach allows each aspect of moving information between 
        the machines to be easily defined and controlled.

        Frye Electronics uses an asynchronous protocol to communicate. 
        This protocol allows much greater flexibility in hardware and 
        software. Because the two machines are not closely tied together 
        in time, the asynchronous protocol allows a greater degree of 
        isolation from the next layer up in the communication protocol. 

        The lowest level protocol provides the definition for 
        transferring information between the two machines it does not 
        insure that the two machines will understand the information that 
        was transferred or that it is error free.

        The ability to detect errors and to provide a common ground of 
        understanding between the two machines is provided by the higher 
        levels of protocol.  These higher levels are usually referred to 
        as communication standards. They define how the data is to be 
        transferred and how to detect errors in the transfer.














              Frye PC Communications Interface Definition    page 2

        The communications standard that is normally associated with 
        RS232 is called ASCII (American national Standard Code for 
        Information Interchange).  It is sometimes referred to as ANSI, 
        but this is a misnomer. ANSI (American National Standards 
        Institute) is the institution that assigned the X3 standards 
        committee to define the ASCII standards. 

        The primary reason for the existence of the two references is as 
        a means to readily identify the two different versions of the 
        ASCII standard. ASCII usually refers to the earlier versions of 
        the standard X3 and X3.1, while ANSI usually refers to the later 
        versions X3.2 and above. The two separate identifications were 
        needed because the later version provides for extensive high-
        level control that was not available in the earlier version of 
        the standard.

        It should be noted that there is no requirement that all 
        components of the standard be implemented on a machine, only that 
        when a component is implemented that it follow the rules defined 
        in the standard.

        The ASCII standard was created with the expectation that the 
        individual using the equipment would be directly involved with 
        the communication. Much of the definition of the ASCII standard 
        is related to that aspect. 

        While there is a limited error detection scheme built into the 
        earlier 7 bit ASCII protocol, there is no definition on what to 
        do if an error does occur. It has been primarily left up to 
        the human being to detect and correct for any error that might 
        occur by observing the data.


























              Frye PC Communications Interface Definition    page 3

        When computers communicate, typically a much larger amount of 
        information is transferred than can be handled with the ASCII 
        protocol. Computers also usually require that the data being 
        transferred be without errors. Since the ASCII protocol was 
        designed for humans and not computers, it is not capable of 
        handling this. To handle the needs of computers a different type 
        of protocol has come into existence. These are referred to as 
        'packet protocols'. 

        The USB and Ethernet communication methods use the packet 
        protocol method to communicate.  

        In a packet protocol, computer data is gathered together in 
        defined groups which are then surrounded with identifiers and 
        error control information. This allows the computers to recognize 
        what the packet is and to know if the information contained in 
        the packet was received without error. If an error occurred, 
        usually a request is made for the information to be re-sent. 
        In more advanced protocols an attempt may be made to try to 
        self-correct the error through reconstruction of the damaged 
        data before asking that the data be re-sent.

        The newer Frye Electronics instrumentation use the Frye 
        Instrument Packet Protocol to communicate with an attached 
        computer. The Frye Protocol was designed to handle the demanding 
        needs of modern computer control over instrumentation.

        An important factor in the design of the Frye protocol was the 
        recognition that the instrument could not always be ready to 
        accept commands from the computer. When the instrument is 
        performing measurements it often simply does not have any extra 
        time available to chat with the computer. As a result of this, 
        the Frye protocol was designed with the concept that the 
        Instrument was the master and the computer was the slave when 
        communicating.

        The instrument that the computer is attached to will send a 'poll 
        request' on a periodic basis when it is ready to accept a command 
        from the computer. The computer must respond within the 
        instrument's poll request time-out period. Typically this is 50 
        milliseconds, although it may be longer on some interfaces such 
        as Ethernet). If a command is not received the instrument will 
        return to its internal measurements. On the model 6500 instrument 
        this repetition time is approximately 0.25 to 0.50 seconds 
        typically while in composite mode. The actual repetition rate is 
        variable depending on the activity of the instrument. The purpose 
        of the poll request is to provide a way to synchronize the 
        computer and test instrument.









              Frye PC Communications Interface Definition    page 4

        The computer tells the instrument to perform actions and thus is 
        the master, but the computer must wait for the instrument to tell 
        it when the instrument is ready to communicate, which makes the 
        computer the slave for communicating. This form of communication 
        is referred to as a 'reversed poll' because the slave is acting 
        as a master, thus reversing its normal role.  Once the command 
        has been sent by the computer, it expects a response back from 
        the instrument within one second. For many commands this is 
        simply an acknowledgment that it received the command.

        Frye protocol definition:

        The Fryers Driver interface provides a common interface that is 
        independant upon the hardware used to perform the communication. 
        The following definition describes the Program to Fryers driver 
        interface. The actual communications link process will be more 
        complex than described here.

        Data is transferred between the computer and the instrument in 
        "packets" which is also referred to as a "transmission block". 
        Each packet is made up of three or more data words (two bytes 
        each, low byte sent first).

        A command is sent to the instrument by a sequence of three 
        packets. A poll packet, a command packet, and a response packet. 
        The poll and response packets are sent by the instrument, and the 
        command packet is sent by the computer. The sequence of the three 
        packets is called a "poll frame", and the action is called a 
        "poll frame sequence". 

        In the 16 bit version of Fryers, a TSR (Terminate and Stay 
        Resident program) called FRYERS.COM is used. Packet sending and 
        receiving is done in the background under interrupt control. The 
        packet data is sent to the send/receive routines through the 
        standard RS232 interrupt (INT14) vector. The FRYERS.COM program 
        provides extended interrupt control by using register AH set to 
        0FFH to access the extended functions. Register AL is set to the 
        specific function to be performed. After loading the FRYERS.COM 
        program and enabling the operation all data is loaded and read 
        through the INT14 vector. 

        The 16 bit version of Fryers operates in the MSDOS environment. 
        It works in Windows V3.1x because Windows 3.1x is actually just a 
        shell program that sits on top of MSDOS, so Fryers becomes a part 
        of the Windows 3.1x operating system.  

        In the 32 bit version of Fryers, a DLL is used. The 32 bit 
        version of Fryers will work with 32 bit Windows such as XP, NT, 
        2K, ME, 98 and 95. It will not work with Windows 3.1x, nor will 
        it work with other operating systems that are not compatible with 
        Windows. If you need to work with MSDOS or Windows 3.1x, you 
        should use the FRYERS.COM TSR. 





              Frye PC Communications Interface Definition    page 5

        The 32 bit version of Fryers uses "threads" to provide the 
        communication with the instrument. With the 16 bit version of 
        Fryers, the TSR hangs around even when the application that uses 
        it terminates. If the program forgot to turn off the TSR, it will 
        also retain control of the serial port. With the 32 bit version, 
        the DLL is kept around only as long as the application uses it, 
        and the serial port is released when the application terminates 
        even if the program forgets to release the port.

        In order to ease the transition for programmers from the 16 bit 
        version of Fryers and to retain a level of reverse compatibility, 
        the 32 bit Fryers DLL uses a calling convention that is similar 
        to the 16 bit calling convention. In most cases, little or no 
        changes to the application code will be required.











































              Frye PC Communications Interface Definition    page 6

        The first packet in the poll sequence is called the poll request 
        packet. It is used to tell the computer that the instrument is 
        ready to accept a command. The computer must respond to the poll 
        request by sending a command packet within the specified poll 
        response time. For most instruments this is 50ms (longer on 
        Ethernet). If the computer does not send a command within the 
        required time the instrument will return to its internal 
        operations and ignore any command from the computer until it is 
        ready to communicate again. Once the send packet is started, the 
        whole packet must be sent. 

        When the command packet is sent to the instrument by the 
        computer, a response packet must be received from the instrument 
        within one second or the computer will assume that the link has 
        been broken and try to re-send the command.

        The whole process is controlled by what is called a "state 
        machine". Specifically what this means is that internal actions 
        occur whenever data is ready to be sent or received on the port 
        by an interrupt signal from the hardware. This frees the computer 
        to perform other activities after sending the command rather than 
        having to spend all its time servicing the communications port 
        waiting on the instrument. 

        In the 32 bit DLL, there is an added complication in that it must 
        operate within the confines of the Windows operating system. What 
        this means is that the thread that communicates with the 
        instrument will "go to sleep" periodically when there is no 
        communication activity. This prevents the thread from hogging all 
        the cpu time while waiting on the attached instrument. 

        The results of the internal actions are available to the high-
        level program through the status function. The status function 
        returns a copy of the internal status of the state machine.

        When an error occurs in the transmission, the low-level routines 
        will automatically attempt to re-send the failed command if it is 
        possible.  Some types of failures that can happen are a checksum 
        error in the sending of data (as indicated by receiving a NAK 
        from the instrument, a checksum error found in the response 
        packet (calculated checksum does not match the received 
        checksum), or a time-out abort as a result of a response not 
        being returned within the expected time period.

        If an error still occurs after ten attempts to retry the command, 
        the transfer error flag will be set, and the command will be 
        terminated automatically. It is then up to the high-level program 
        to determine the next course of action.









              Frye PC Communications Interface Definition    page 7

        Data is loaded into the send buffer and sent through the use of 
        the send command.  A packet send can be canceled at any time if 
        so desired. If the packet did not get through, it will 
        automatically be re-sent if the problem was a transmission error 
        (as noted by a checksum error). If the returned response is 
        "Invalid command", it is assumed that the programmer made a 
        mistake and the packet is not re-sent. It is up to the high-level 
        program to re-issue the corrected send data command. 

        A command is sent to the instrument by building an array of 
        integer words (two bytes each) and issuing commands to send the 
        data. A maximum of 1000 words may be transferred to the send 
        buffer. After the send command is given you may sit and watch the 
        status, or go do something else. You may look at the I/O status 
        at any time.  

        When the send command is given, the data is copied to the 
        driver's internal send buffer. Once the data has been copied, the 
        send ready flag is cleared. The send routine then waits for a 
        poll request packet from the instrument. 

        When a valid poll request is received, the command will be sent 
        to the instrument. The low-level routine will then wait for the 
        returned response from the instrument. The returned response must 
        be a valid response packet. A valid response consists of a packet 
        with a good checksum, a valid data size, is not a poll request 
        packet, and is not a NAK response packet. When a valid response 
        is received the receive ready flag will be set.

        A poll synchronization response from the instrument is assumed to 
        be the same as a checksum error since it indicates that the 
        instrument never received the original request. A receive 
        overflow has the same effect as a checksum error. A NAK response 
        will also cause a re-send to occur. A NAK response occurs when 
        the instrument detects a checksum error in the command packet.

        An illegal command response will not trigger an automatic resend.

        A command packet consists of a command word, a data length word, 
        optional data, and ending with a checksum.

        Example:       Command word
                       Data length word
                       - optional data -
                       Checksum

        The checksum in the packet is based on the entire packet 
        including the command word, data length word, and any data that 
        might be included in the packet. The result is then inverted 
        (logical not) which becomes the checksum that will be sent.







              Frye PC Communications Interface Definition    page 8

        The checksums are handled automatically by the low-level driver. 
        The high-level application program does not need to perform 
        checksum generation or verification. If a checksum error is 
        detected by the low-level driver it will automatically re-send 
        the command. This insures that the data will be transferred 
        reliably between the computer and the instrument. 

        Occasionally the link between the instrument and the computer may 
        be defective or broken entirely.  If this happens the low-level 
        program will suspend communications with the target machine until 
        the problem has been corrected. 

        There are three basic forms of communication failure that can be 
        detected by the low-level driver; 1 - Damaged data during a 
        transfer. 2 - Loss of data during a transfer.  3 - Loss of poll 
        synchronization.  

        1 - Damaged data is detected by the checksum handlers which test 
        the data that is transferred between the machines for any errors. 

        Damaged data can be the result of environmental interference such 
        as a static discharge, or a high-powered electromagnetic device 
        near the transmission cables.  It can also be caused by defective 
        or marginal cabling between the machines. Another cause of 
        damaged data is defective or improperly configured equipment. 

        2  - Lost data is similar in nature to damaged data,  but instead 
        of just being damaged it is missing entirely.  Usually other data 
        in the transfer is damaged in addition to data being lost. 

        Lost data is detected by the time window detectors. When data is 
        not received within the expected time window it is assumed to be 
        lost. The cause of lost data is usually the same as that for 
        damaged data. 

        3 - Loss of poll synchronization is usually the result of a 
        damaged communication link between the two machines, or an 
        improper configuration. Detection of lost synchronization is 
        performed by an internal watchdog timer that looks for the 
        continuous stream of expected polls from the instrument.  

















              Frye PC Communications Interface Definition    page 9

                                  Flag handling 

        There are a number of flags that are returned by the driver so 
        that the high-level application program can observe the activity 
        of the driver.

        Of these flags, only the Status Flags are of primary concern for 
        normal program operation. The other flags are provided as a 
        convenience for the programmer to assist in discovering why a 
        particular error has occurred.

        The status and error flags are always returned in register AX 
        after any command that affects the packet control. Other 
        information may or may not be returned depending on the function 
        performed. 

        The primary transfer control flags are the send ready flag and 
        the receive ready flag. The send ready flag is used to indicate 
        when a command may be sent and when a response has been received. 
        The receive ready flag is used to determine if the response that 
        was received is valid. 

        There are two error flags associated with the send ready flag, 
        the send overrun flag and the send overflow flag. These two flags 
        can be tested after a send command is given to insure that it was 
        accepted. If the command is valid and the send ready flag was 
        on before the command was given these flags will not be set on.  
        They can be ignored if you are sure that the command was properly 
        given. The two send error flags are cleared when the next send 
        command is given.

        Normally the transfer error flag will not be set on by the send 
        error conditions. The transfer error flag indicates when the data 
        in the receive buffer or the send buffer is bad. Since the send 
        buffer is never loaded if a given command is bad this will not 
        normally happen. If an attempt is made to send a command in the 
        send buffer that is damaged or it is damaged in the middle of a 
        transfer (see the re-send and send buffer load functions), then 
        the transfer error flag is set on and the transfer aborted.

        The receive overrun error will only be set on if a response was 
        not read from the receive buffer before the next response was 
        received. If the receive buffer is always read before the next 
        send command is given this error will not occur.

        Normally the transfer error flag will not be set on by the 
        receive overrun error condition. The transfer error flag 
        indicates when the data in the receive buffer or the send buffer 
        is bad. Since the data that was received is good, the error flag 
        is not set on. If the data is found to be damaged when the 
        receive buffer is read the overrun flag will be set. The receive 
        overrun flag will be set anytime data in the receive buffer is 
        changed when the receive ready flag is on.




              Frye PC Communications Interface Definition    page 10

                               Packet Status Flags

        The packet status flags are the primary flags used to detect 
        errors and control data transfer.

        The packet status flags are provided as a means to determine the 
        current condition of the packet transfer. These flags are to be 
        used to determine when a transfer has been completed and if the 
        response was valid or not.


        Send ready flag:                             Status flags - Bit 0

        When the driver is ready to accept a command it will set the send 
        ready flag on. The flag remains on until a send command is issued 
        by the high-level application program. 

        When a send command is given it will cause the send ready flag to 
        be cleared to an off condition indicating that the command was 
        accepted. Any data specified will be copied to the send buffer. 
        As the data is copied from the send buffer the checksum is 
        calculated and is attached to the end of the packet to be sent.

        The send ready flag will be set on again upon receiving a valid 
        response from the instrument, or if the send command is aborted 
        either automatically, or manually through the reset command. 

        When the send command is given, the driver will copy the data 
        into the send buffer and start the send process. The programmer 
        can abort the send at any time with the reset command. Care 
        should be used with this command though since the transmission 
        block will be terminated without finishing the transfer which may 
        confuse the receiving instrument.

        If an error occurs in the poll frame sequence that can be 
        detected by the driver and corrected, it will attempt to re-send 
        the command. Another send command will not be accepted until a 
        valid response packet has been received from the instrument. 



















              Frye PC Communications Interface Definition    page 11

        Receive ready flag:                          Status flags - Bit 1

        The receive ready flag is set on when a valid response has been 
        received from the instrument. It is cleared to an off condition 
        by the high-level application program reading the data from the 
        receive data buffer.

             A valid response consists of:

                  1. Not a Poll request.
                  2. Not a NAK response.
                  3. Good checksum.
                  4. Valid data size.

        The receive ready flag is updated when the received checksum is 
        complete. The receive ready flag is set on or off based upon the 
        error information indicated above (poll, NAK, checksum, data 
        size). Note: an ILL response is considered by the driver to be a 
        valid response. It is up to the high-level application program to 
        deal with an ILL response.

        When the entire data block is received, the checksum is tested. 
        If the checksum is good, and the block is not a Poll response, 
        not a NAK response, and the size is valid, the receive ready flag 
        will be set on.

        If the checksum is bad, or a poll block was received, or a NAK 
        was received, or the size was incorrect, then an automatic re-
        send will occur, and the receive ready flag will remain off. If 
        after ten re-tries a valid response is not received, the command 
        will be aborted, and the receive ready flag will not be set on. 
        (Use the send ready flag to determine when the transfer is 
        complete.) Data in the response buffer is only valid when the 
        receive ready flag is on. 

        There is a four step sequence to receiving data. To start, the 
        send command is given.  When a valid poll request is received 
        from the instrument the command packet is sent. Sometime later 
        the instrument will respond with a response packet.

        Any data received from the instrument is copied into the receive 
        buffer as it is received. The number of words specified in the 
        size word (second word in the received packet) will be the number 
        of data words copied to the receive data buffer. If more than the 
        specified number of words are received, a poll sequence error 
        will probably occur, since further data is ignored by the receive 
        routine. 

        Note: Since the instrument does not normally respond to a Quick 
        Terminate command, the receive ready flag will not be set unless 
        there was a problem with the Quick Terminate command. The Quick 
        Terminate command is the one exception where a valid command will 
        not set the receive ready flag. Only the send ready flag will be 
        set as a result of a Quick Terminate command.



              Frye PC Communications Interface Definition    page 12

        Send overrun flag:                           Status flags - Bit 2

        The send overrun flag is set on if an attempt is made by the 
        high-level application program to issue a send command while one 
        is already in progress.  If the send overrun flag is on, the send 
        command that caused it to be set on will be ignored. 

        The send overrun flag is cleared to off when the next send 
        command is given. It can also be cleared to an off condition with 
        the reset command.


        Send overflow flag:                          Status flags - Bit 3

        This flag indicates that the data size specified is too big to 
        fit in the send buffer. The packet must be 1024 bytes or less. 
        (Note: the data size must also fit the instrument or it will be 
        rejected by the instrument.)

        The send overflow flag is updated when the send command is given. 
        If the send overflow flag is set on, the command will not be 
        sent. The command will not be sent until the data size is valid. 

        Checking on the validity of the data being sent is not done. It 
        is up to the programmer to insure that the proper data is placed 
        in the send buffer. It is also assumed that the programmer will 
        use the correct data size with the data in the buffer. 

        Default data size is zero on startup. It will remain in the last 
        set condition until changed by the programmer. A data packet size 
        of zero will cause no data to be sent with the command. A data 
        packet size of -1 will cause nothing to be sent at all and the 
        send overflow flag will be set on.


        Receive Overrun flag:                        Status flags - Bit 4

        The receive overrun flag will be set on if the receive ready flag 
        is on when a new response is received in the receive buffer.  The 
        old response in the receive data buffer will be replaced by the 
        new data and the overrun flag will be set on. 

        Normally a receive overrun is a result of the high-level program 
        not reading all the data from the receive buffer before the next 
        response is received. 

        The receive overrun flag is updated at the start of receiving the 
        response packet. If the receive ready flag is on, the receive 
        overrun flag is set on, otherwise it is cleared to an off 
        condition. 







              Frye PC Communications Interface Definition    page 13

        Packet Disabled flag:                        Status flags - Bit 5

        Bit 5 of the status flags is used to indicate that the packet 
        driver has not been enabled yet. Prior to V3.00 this bit was 
        always zero. It is high (1) whenever the packet driver has not 
        been turned on. The transfer error flag is also set on.


        No poll:                                     Status flags - Bit 6

        If 5 seconds have passed (this is adjustable) since the last poll 
        synchronization signal was received from the instrument, the no 
        poll flag will be set on.  It is cleared to an off condition 
        again by receiving a poll synchronization signal from the 
        instrument.

        It should be noted that there are normal conditions when poll 
        synchronization will be lost from the instrument.  This will 
        happen when certain automatic modes of operation are entered on 
        the target instrument, or when internal operations in the 
        instrument exceed the time-out period.

        One example of an extended time delay on the Frye 6500 model 
        instrument is when a pure tone sweep is requested with noise 
        reduction set to 16. This will take about one minute to perform 
        the sweep which is well beyond the normal default five second 
        time-out period.

        There are two ways to handle the normal loss of poll. The loss of 
        poll synchronization will not terminate a command in progress, 
        nor will it inhibit a command from being given. The command will 
        not be sent however until synchronization has been achieved 
        again. Thus you can simply go ahead and give the command anyway 
        and ignore the no poll flag. 

        Alternately you could change the time-out value to extend to two 
        minutes (or whatever maximum time you feel comfortable with), you 
        can then use the no poll flag as a true error flag and terminate 
        the command when it is set on.  

        The no poll flag itself does not cause any error handling to 
        occur within the low-level driver. Any command that might be in 
        progress will not be affected. A reset command will cancel any 
        pending send command, but it will not clear the no poll flag, 
        only a new poll synchronization signal from the instrument can 
        clear the no poll flag. The purpose of the no poll flag is to 
        notify the high-level application program that an error condition 
        might exist, it is up to the high-level application program to 
        make the decision on what to do.

        The default value of five seconds (5) is selected when the packet 
        mode is enabled. The value can be changed with the packet time-
        out set command.




              Frye PC Communications Interface Definition    page 14

        Transfer error flag:                         Status flags - Bit 7

        This flag is set on when an error has occurred which caused the 
        data transfer to be invalid. It is a compilation of the other 
        error flags. It can be used to determine if valid data exists as 
        a response to a command sent to the instrument. 

        The flag will also be set on by an incomplete transfer error 
        which can happen as a result of a send abort, or a forced time-
        out abort.  Normally no action needs to be taken because the low-
        level routine will automatically re-send the request packet when 
        this error occurs. 

           The conditions that will cause the flag to be set on are:

           Checksum error on response packet (received data was damaged)
           Poll request received as a response packet (cmd never rcvd)
           NAK received as a response packet (cmd was damaged)
           Receive overflow condition  (data too big)
           Receive time-out condition  (data was lost)
           Response time-out condition (no data received)
           Manual or auto abort of transfer (too many, or forced, errors) 


        The flag is cleared to an off condition when a new send command 
        is given. It is also cleared to off when an automatic re-send 
        occurs.


        The transfer error flag is used to indicate the condition of the 
        data in the receive buffer. When the flag is set on the contents 
        of the receive buffer are invalid. The transfer error flag is 
        used by the low-level driver to determine if an attempt should 
        be made to re-send the command. Error conditions that do not 
        cause this effect will not set the flag on. 

           Error conditions that will not set the flag on are:

           Send overrun condition    (command is ignored)
           Send overflow condition   (command is ignored)
           Receive overrun condition (good contents but old data is lost)

        Notes: The two primary flags of interest are the Send Ready flag 
        and the Receive ready flag. When the Send Ready flag is on 
        (high), a command may be sent. When the Send ready flag is off 
        (low), the command is in progress. When the Send Ready goes on 
        again, the command has been completed. You may then look at the 
        Receive Ready flag to see if the response is valid. If the 
        response is not valid the error flags may be looked at to find 
        out why.  







              Frye PC Communications Interface Definition    page 15

                               Packet Error Flags

        The packet error flags are provided as a means to determine what 
        type of error has occurred when the Transfer error status flag is 
        set.  The flags are a copy of the internal error control flags, 
        and as such will not be stable while a packet transfer is in 
        effect. These flags will only be stable when the Send Ready flag 
        is on (high) indicating that the transfer is complete. 


        Checksum error flag:                          Error flags - Bit 0

        When the received response packet has a checksum error, this flag 
        will be set on, otherwise it will be cleared to an off condition. 
        It will remain on or off until the next response packet is 
        received. This flag is updated upon completion of receiving the 
        response packet since the entire contents of the packet must be 
        received to calculate the checksum. 

        If the checksum received is good, then the receive ready flag 
        will be set on, and the checksum flag is cleared to an off 
        condition. If the checksum is bad, the checksum flag is set on 
        and the original command will be re-sent to the instrument from 
        the send buffer. This will repeat until ten retries have 
        occurred, or the send is terminated by a reset command from the 
        high-level program, or until a response packet without a checksum 
        error is received. 

        If a poll is received as a response packet, it is considered the 
        same as a checksum error by the low-level driver even though the 
        checksum error flag is not set on. The poll response flag will be 
        set on instead. 

        Sometimes a NAK may be received as a response. This will happen 
        if the instrument found a transmission error in the data as 
        indicated by a bad checksum. The low-level driver will treat a 
        NAK response the same as a checksum error, but the NAK response 
        flag will be set on instead of the checksum flag.

        For a good response packet to be accepted the receive ready flag 
        must be set on, the poll response flag, the receive overflow, NAK 
        response, and the checksum flag must all be off.

        An Invalid Command response (ILL) from the instrument is 
        considered a high-level error, and it is up to the high-level 
        application program to determine how to handle it. 

        The checksum flag is for internal use, and should not be relied 
        on by a program other than for testing purposes. 

        Note: checksum is not performed during idle poll sync time. 
        Checksum error detection is an inherent part of the poll 
        synchronization process.




              Frye PC Communications Interface Definition    page 16

        Poll response flag:                           Error flags - Bit 1

        This flag is set on when the first word in a received response 
        packet is 0FFFFH (-1). It is updated immediately upon receiving 
        the first word of the packet. It remains on or off until the 
        first word of the next response packet is received. If after ten 
        attempts at re-sending the command, a non-valid response is still 
        obtained from the instrument, the send command will be 
        automatically aborted.


        NAK response flag:                            Error flags - Bit 2

        This flag is set when a NAK response is received from the 
        instrument. It is set on when the first word of a response packet 
        contains a -6 (FFFAH). It is cleared to off if the first word is 
        anything else. 

        A NAK is sent by the instrument when it finds a checksum error in 
        the data sent to it. The instrument will not act on the command. 
        It will instead respond with the NAK. The low-level driver will 
        automatically re-send the command to the instrument when this 
        happens. If after ten attempts at re-sending it is unable to get 
        a valid response from the instrument, the send command will be 
        automatically aborted.


        Receive Overflow flag:                        Error flags - Bit 3

        Occasionally a response packet may be damaged in a way that 
        causes the data size word to contain a value that is too large to 
        fit in the response buffer. If this happens, the following data 
        will not be received since it is not known how much real data 
        there might be. 

        When a receive overflow occurs the receive overflow flag will be 
        set on and the poll synchronization state will be immediately re-
        entered. When a valid poll synchronization has again been 
        received, the previous command will be automatically re-sent.

        The receive overflow flag is updated when the second word in the 
        response packet is received. If the word is larger than the data 
        buffer can hold, the flag will be set on, otherwise it is cleared 
        to off. 

        Note: If the overflow flag is on the receive ready flag will not 
        be set on since the data is not valid.  If this flag is on, the 
        response receive will be immediately stopped, and the response 
        discarded. The poll synchronization will then be re-enabled.

        The flag is only updated during response receive (not during idle 
        sync). If the previous response has been read, the flag will be 
        cleared, otherwise it will be set on.




              Frye PC Communications Interface Definition    page 17

        Receive time-out flag:                        Error flags - Bit 4
        If while in the middle of receiving a packet, a period of time 
        greater than 0.1 second goes by without receiving the next 
        character, it is assumed that the link has been broken, and a 
        receive time-out will occur. The 0.1 second time-out is 
        approximate, it may vary by as much as -20% +80% depending on 
        activity in the computer.  The default value of 0.1 second is 
        selected when the packet mode is enabled see the packet time-out 
        set command to change the value if needed. Note: this is 
        primarily an effect on RS232 interfaces. USB and Ethernet 
        interfaces are not affected by this aspect.

        The flag is cleared to off when the next packet character is 
        received.  It is also cleared to off by the reset command. 
        Normally no action needs to be taken because the low-level 
        routine will automatically re-send the command packet when this 
        error occurs. When a response is being received, and this flag is 
        on, it will cause the transfer error flag to be set on. During 
        poll synchronization it will cause a restart of the poll 
        synchronization logic.

        Response time-out flag:                       Error flags - Bit 5
        When a command packet is sent, a response packet is expected from 
        the instrument within one second.  If the first character of the 
        packet is not received within the one second time-out period, it 
        is assumed that the link has been broken and a response time-out 
        will occur. This timeout is adjustable.

        The one second time-out is approximate, it may vary by as much as 
        -20% +80% depending on activity in the computer. Normally no 
        action needs to be taken because the low-level routine will 
        automatically re-send the command packet when this error occurs. 
        The flag is cleared to an off condition when a send command is 
        given. It can also be cleared off by the reset command. The 
        default value of one second is selected when the packet mode is 
        enabled see the packet time-out set command to change the value 
        if needed.

        * Note: The low-level routine only deals with time-outs involved 
        with sending and receiving packets. It cannot test for time-outs 
        resulting from no poll from the instrument. There can be periods 
        of time lasting many seconds or minutes in which a poll might not 
        be sent, or other actions in which the instrument may not send a 
        poll because it is busy. 

        It is up to the high-level application program to determine that 
        there has been no response to the command sent. The lack of 
        response may be because the communications link has been broken 
        (such as a broken wire, or disconnected cable), or because the 
        instrument is not operational (turned off, or communications mode 
        not enabled). The poll synchronization repetition time of the 
        instrument will vary depending on the current state of the 
        machine. The synchronization time may be as short as 10 
        milliseconds, or it may stretch out to many seconds.



              Frye PC Communications Interface Definition    page 18

        I/O error flag:                               Error flags - Bit 6

        This flag is set on when a low-level error is encountered from 
        the hardware (such as the UART), such as a Break or overrun 
        error. This flag should not be used to determine when a valid 
        response packet has been received since it does not provide that 
        information. The I/O error flag is used internally and provided 
        primarily for testing purposes. 


        Retry time-out flag:                          Error flags - Bit 7

        When a transfer error occurs, such as a checksum error on the 
        response packet, or a NAK response received, the low-level 
        driver will automatically re-send the command packet on the next 
        poll request. 

        The retry will be attempted ten times. If a valid response is not 
        received from the instrument, after ten times of trying to re-
        send the command, the command will be aborted and the retry time-
        out flag will be set.  


             The conditions that will cause a retry attempt to occur are:

             Checksum error on response packet
             Poll request received as a response packet
             NAK received as a response packet
             Receive overflow condition
             Receive time-out condition
             Response time-out condition


        Note: A retry is not done on send overflow or send overrun 
        because these errors will not allow the command to be sent in the 
        first place. A retry is also not performed on a receive overrun 
        condition since the original command for the response that has 
        been lost is not known. It is up to the high-level program to 
        detect these errors and decide what to do.

        An Invalid Command (ILL) is not considered a failure by the low 
        level driver, so it will not trigger a resend. It is up to the 
        high-level application program to decide what to do about an 
        invalid command.













              Frye PC Communications Interface Definition    page 19

                              Packet control flags

        These flags reflect the current internal conditions of the packet 
        transmission. The flags are a copy of the internal state of the 
        packet control. They are provided primarily for testing purposes 
        and should not be used to determine if a response is available or 
        valid. 


        Poll sync flag:                             Control flags - Bit 0

        This flag is set on when the first byte of a poll synchronization 
        packet is received. It is cleared to off when the last byte is 
        received. 

        This flag is for internal use, and should not be relied on by a 
        program other than for testing purposes.

        A complete poll synchronization request is identified by the 
        three word sequence of 0FFFFH, 0000H, and 0000H. During idle 
        state the low-level driver will automatically attempt to 
        synchronize to the poll request. The instrument is expected to 
        periodically send poll requests. It is this repetition that is 
        used to synchronize the machines. 

        When there is nothing to be sent, the low-level driver will wait 
        for poll synchronization requests to be sent to it from the 
        instrument. If a non-poll sync request packet is received, the 
        program will re-adjust until it sees one. It does this by looking 
        for the received byte sequence of "FF,FF,00,00,00,00" if it does 
        not receive each of the bytes in the proper sequence it will 
        start over at the beginning of the sequence until it finds the 
        entire sequence. 

        When a send data command is given, the low-level driver will 
        wait for a valid poll sync request packet. When the poll sync 
        request packet is received the command packet will be sent. Once 
        the command has been sent, the poll request synchronization is 
        disabled, and any packet received is copied to the receive 
        buffer. When the entire packet has been received, the idle state 
        of poll request synchronization is re-entered.


        Poll active flag:                           Control flags - Bit 1

        This flag is set on when a valid poll request is received after a 
        send command has been given. It is cleared to off when a response 
        (good or bad) is received. This flag should not be used to 
        determine when a valid response packet has been received since it 
        does not provide that information. The flag is used internally 
        and provided primarily for testing purposes.






              Frye PC Communications Interface Definition    page 20

        Sending packet flag:                        Control flags - Bit 2 

        When a command packet is being sent this flag will be set on. It 
        is reset to off when the last word in the packet is sent. This is 
        for internal use, and should not be relied on by a program other 
        than for testing purposes.


        Awaiting response flag:                     Control flags - Bit 3

        This flag is set on while waiting for the response packet from 
        the instrument. If the specified time-out period goes by while 
        this flag is on, a response time-out abort will occur. 

        This flag should not be used to determine when a valid response 
        packet has been received since it does not provide that 
        information. This flag is used internally and provided primarily 
        for testing purposes.


        Receiving response flag:                    Control flags - Bit 4 

        This flag is set on when a response packet is being received. It 
        is set on when the first word is received, and cleared to off 
        when the last word has been received. 

        This flag is for internal use, and should not be relied on by a 
        program other than for testing purposes.


        Baudrate Error Detect flag:                 Control flags - Bit 5 

        This flag is set on when the packet engine has determined that 
        the baudrate is incorrectly set (multiple poll errors). It is 
        cleared when a valid poll is received. 


        Auto Quick Terminate Active:                Control flags - Bit 6 

        This flag indicates when an auto-terminate of the poll is 
        occurring. The default action of the AutoQT function is to send a 
        QT message in response to the poll if no cmd is waiting to be 
        sent. If an ILLCMD is received in response to three QT commands 
        in a row, the AutoQT function will be disabled. A valid command 
        sequence will clear the disable count to prevent inadvertently 
        disabling the AutoQT feature.

        This flag is for internal use, and should not be relied on by a 
        program other than for testing purposes.








              Frye PC Communications Interface Definition    page 21

        Transfer aborted flag:                      Control flags - Bit 7 

        This flag is set to on when a transfer is aborted. This can be 
        caused by either an automatic abort due to a time-out on retry, 
        or when a reset command is given while a send is in progress.
        This flag will be cleared on the next send command.

        Note: since the reset clears all the error flags to off, this is 
        the only flag that can be used to determine if the abort was done 
        via the reset command.


        Packet Baudrate Synchronization Seek flag:  Control flags - Bit 8 

        This flag is set on when the packet engine has determined that 
        the baudrate is incorrectly set (multiple poll errors). And a new 
        baudrate has been selected by the calling program. If packet 
        synchronization has not been achieved within eight attempts at 
        synchronization, the flag will be cleared (bit 5 will remain 
        set). Alternately, the flag will be cleared if synchronization 
        has been achieved (bit 5 will also be cleared).  

        This flag is for internal use, and should not be relied on by a 
        program other than for testing purposes. It is used by RS232 and 
        simulated RS232 (such as USB) port interfaces. 


        Packet Flush flag:                          Control flags - Bit 9

        This flag will be set when a packet is being discarded by the 
        internal packet engine due to lost synchronization.

        This flag is for internal use, and should not be relied on by a 
        program other than for testing purposes.


        Skip Poll flag:                            Control flags - Bit 10

        This flag will be set when a skip poll action is initiated either 
        internally or by an external request. It is cleared on the next 
        valid poll sequence.

        The flag may be triggered by a skip poll request request, or by 
        an internal Quick Terminate response failure (ILLCMD), the skip 
        poll flag is used to perform a skip poll action to release the 
        instrument. This helps speed up command sequences on Fonix 
        instruments that do not understand the Quick Terminate command. 

        It is possible to get more speed if you do your own skip poll 
        action if you know the instrument does not understand a Quick 
        Terminate command since it would eliminate the extra QT/ILL 
        command sequence, but compared to the traditional 100ms wait, it 
        is faster.




              Frye PC Communications Interface Definition    page 22

        Quick Terminate Fail:                      Control flags - Bit 14  

        This flag indicates if there has been a failure of a Quick 
        Terminate command. It is cleared on the next valid poll sequence. 
        Note that this is different from the QTflag value returned by 
        FF1A (that flag is set when it is determined that the instrument 
        cannot support Quick Terminate). This flag is only set during a 
        failure of a single Quick Terminate attempt (either manual or 
        automatic). 

        This flag is for internal use, and should not be relied on by a 
        program other than for testing purposes.


        Send timeout:                              Control flags - Bit 15

        This flag is used in 32 bit mode to indicate a timeout while 
        sending a packet. It is used internally to cancel the control 
        communications thread. 


        Spare bit 10                               Control flags - Bit 10 
        Spare bit 11                               Control flags - Bit 11 
        Spare bit 12                               Control flags - Bit 12 
        Spare bit 13                               Control flags - Bit 13 
        Spare bit 14                               Control flags - Bit 14 

        These flag bits are currently undefined and are reserved for 
        future use. While they are currently returned as zero, you should 
        not rely of the bits being returned as any specific value. They 
        may take on new definitions in the future. 


























              Frye PC Communications Interface Definition    page 23

        Autobaud (RS232 ports):

        With version 2.05 of the Fryers driver a new autobaud detection 
        feature was added. Autobaud detection was used when the Fryers 
        packet mode was enabled and the parity was selected for autobaud 
        operation. This feature was dropped in V4.00 (see below).

        When the autobaud feature was selected, the Fryers driver would 
        attempt to synchronize to the baud rate of the attached 
        instrument. The baudrates were cycled one at a time looking for a 
        valid poll packet from the instrument. The starting baudrate 
        would be the baudrate that was initially programmed into the 
        computer's uart. The baudrates that were searched were 9600, 
        19200, 28800, 38400, and 56000. 

        In Version 4.00 this was changed to deal with problems when being 
        run under virtual machine hardware (such as with Windows). A 
        serious failure could occur if an attempt was made to change the 
        baudrate from within the service routine. To deal with this, the 
        driver no longer tries to set the baudrate inside the service 
        routine. Because of this, the baudrate can no longer be 
        automatically managed. It must now be controlled by the 
        application. To ease this issue, a new function was added (Set 
        Packet AutoBaud), which will manage the baudrate if it is called 
        periodically so that it can monitor the packet engine and 
        determine if a baudrate change is required.

        When eight poll request blocks are received in error, this 
        signals the packet detector that the baudrate may be incorrect. 
        The AUTOBD flag will be set requesting that a new baudrate be 
        tried. If nothing else is done, the AUTOBD flag will be cleared 
        when a valid poll has been received. If a new baudrate is 
        specified, the synchronization seek flag will be set, and the 
        packet engine will try to synchronize to the new baudrate. If 
        after eight tries synchronization is not achieved, the 
        synchronization seek flag will be cleared (the AUTOBD flag will 
        remain set to indicate that the baudrate may still be incorrect).
        The calling program may then try yet another baudrate until 
        synchronization has been achieved.
         
        In order to not mistake inactivity as a loss of synchronization, 
        the autobaud detector ignores 'no poll' situations. Additionally, 
        the detector will only be active when a poll message is expected 
        from the attached instrument. Errors while sending a command or 
        receiving a response will not be counted. Only an active poll 
        message on the communications port will cause the autobaud 
        detector to become active. 










              Frye PC Communications Interface Definition    page 24

        It should be noted that it can possibly take several seconds to 
        re-synchronize to a baudrate if the old one is lost for some 
        reason. This is caused by the need to test a poll sequence at 
        each baudrate before moving on to the next baud rate to test. 
        Thus bad polls (such as might be caused by a bad cable or 
        connection) will cause the autobaud detector to have to cycle 
        through all the auto-baudrates waiting for synchronization at 
        each baudrate before synchronization is achieved again. The exact 
        time that this will take is dependent upon the poll repeat time 
        of the attached instrument.

        Once the baudrate has been detected (by receiving a valid poll), 
        the baudrate detector is deactivated and will not trigger again 
        until eight successive bad poll sequences are received. Receiving 
        even one good poll sequence out of eight is enough to prevent the 
        baudrate detector from becoming active. 

        The baudrate detection feature was provided to allow 
        compatibility to equipment which may communicate at faster 
        baudrates than the original standard 9600 baud. Newer Frye 
        equipment may communicate at faster speeds.

        Poll Error Counter:
             
        Starting with version 2.11 a poll error counter was added to 
        provide debug information about how many poll errors have 
        occurred since Fryers was last loaded. This can be useful to 
        determine if there is a defective link or if you have programming 
        problems. Note that there may be some startup errors that will 
        occur when the communications port is first initialized. This is 
        caused by out of sync poll signals coming from the instrument. 
        Normally you should only see a few errors occur each time the 
        port is initialized, reset, or a new baudrate is selected.

        It should be noted that in the 32 bit DLL version for the driver, 
        there can also be errors that occur when the Windows screen saver 
        is engaged. This is caused by Windows telling the DLL to go to 
        sleep when the screen saver comes on. This will normally not 
        affect operation other than the DLL cannot communicate when the 
        screen saver is on. It will however cause errors to occur when 
        the screen saver is engaged. If you need the Fryers DLL to 
        communicate all the time, you should turn off the screen saver. 

        Also keep in mind that some functions in Windows can take a 
        lengthy period of time to complete and that they can interfere 
        with communications. Under normal operation this should not cause 
        any problems, but you might see time-out retry errors occur when 
        starting up another application while the Fryers DLL is 
        communicating. 








              Frye PC Communications Interface Definition    page 25

        Quick Terminate:

        The Quick Terminate function allows for faster transfers by 
        automatically canceling the poll request if no command is waiting 
        to be sent. This allows the instrument to not have to sit around 
        waiting for the poll request to time-out. 

        When a poll is received, Fryers will check to see if a command is 
        waiting to be sent. If there is a command message waiting, Fryers 
        will send it. If not, and the auto quick terminate is enabled, 
        Fryers will instead send a Quick Terminate command. If Fryers 
        receives an ILLCMD in response to the Quick Terminate command, it 
        will cancel the Automatic Quick Terminate operation. 

        The AutoQT function is enabled when the packet operation is 
        enabled, or when the packet reset function is called. It can also 
        be enabled separately by calling the Quick Terminate enable 
        function. The AutoQT function will remain enabled until either an 
        ILLCMD is received in response to a QT message, or it is turned 
        off by calling the AutoQT disable function. 

        Poll Delay:

        An associated function in newer instruments is the ability to set 
        the poll request time-out delay time. The standard default poll 
        time is 50 milliseconds. Most instruments will allow this to be 
        reduced to 10 milliseconds. The poll delay should never be set to 
        less than 10 milliseconds since Fryers will not be able to 
        synchronize to the poll packet without the 10 millisecond delay 
        needed to identify that it is a poll packet. For Windows systems, 
        the poll timeout should not be set below 25 milliseconds. 

        While the quick terminate function is faster since it immediately 
        responds to the poll request, reducing the poll delay time can 
        help to improve the speed of the attached instrument when the 
        Fryers driver has been turned off. When Fryers is not active, it 
        cannot respond to the poll requests. That means that the 
        instrument must revert to the time-out of the poll request to 
        know whether the computer is going to respond to the poll 
        request. By reducing the poll request delay time, the time-out 
        period can be reduced allowing the instrument to not have to sit 
        and twiddle it's thumbs for as long a period when Fryers isn't 
        talking to it. For some newer instrument, polling occurs in the 
        background, so the poll timeout is not an issue. 

        Be careful about setting the poll delay time to too small of a 
        value. If you are not using Fryers and/or are operating on a 
        computer system that cannot respond quickly to a poll request, 
        such as from a Basic program, or from a Unix system, it is 
        possible to set the poll delay to a value that makes it 
        impossible to respond to the poll in time. This may cause the 
        instrument to not respond or to operate in an erratic fashion. 





              Frye PC Communications Interface Definition    page 26

        How the send is done:

        Load the send data buffer by feeding it data with either the Send 
        command (0FF11H) or with a combination of Indexed write to Send 
        buffer (0FF23H) and Send command packet (0FF15H).

        Once the send command has been given, the command will be copied 
        to the internal send buffer. The data size byte will be checked 
        to see if it is valid before the actual send occurs. If it is too 
        big (over 1000 words) the send overflow flag will be set on, and 
        the send command will be ignored.

        If a send is in progress already when a send command is given, 
        the send overrun flag will be set on, and the new send command 
        will be ignored (the prior send command will continue 
        unaffected).

        If the send command is accepted, a checksum will be calculated 
        and added to the end of the command. You do not need to worry 
        about checksums, they are handled automatically by the driver.

        The send command can only be given when the send ready flag is 
        on. When the send command is given the send ready flag will go 
        off, you should then wait for the send ready flag to go on again, 
        which indicates that the transfer is finished.

        If an error occurs in the transfer, the low-level routines will 
        automatically resend the command until a good transfer occurs, or 
        ten re-tries whichever comes first. The high-level program can 
        abort the send at any time with the reset command. 

        When a valid response is returned the receive ready flag is set 
        on and you may read the data from the receive buffer.

        If you do not read the returned response from the receive buffer 
        before the next response is received you will get a receive 
        overrun error, and the new received response will replace the 
        unread data in the buffer.

        The simplest type of transfer that can be done is the "blind 
        transfer". In this case you assume that no errors will ever 
        happen. You only need to look at the send ready flag to perform 
        this type of transfer. 

             1. Check to be sure that send ready is on (high).
             2. Send the command.
             3. Wait for the send flag to go on (high) again.
             4. Read the receive buffer.

        Since the low-level driver does error handling this will work 
        90% of the time, but where 100% accuracy is required some form of 
        error checking should be done. 





              Frye PC Communications Interface Definition    page 27

        How to send a command:

        1. Check the send ready status to make sure you can do the send
        (function 0FF13H in AX).

        2. Either do a send command by providing a pointer to an integer 
        array in registers DS:BX (16 bit) or EBX (32 bit) with function 
        0FF11H, or load the send buffer with function 0FF23H and trigger 
        the send command action with function 0FF15H. The checksum is 
        calculated by the computer, so you don't need to worry about it.

        The Fryers driver will take it from there. When you give the send 
        data command, first a check is done to see if there is a pending 
        data command. If there is, then the new data will not be sent. 
        The buffer copy will not take place and the send overrun flag 
        will be set on. The current command in progress will continue 
        unaffected. You must use the reset command if you wish to abort a 
        send command in progress. 

        If the send command is accepted, then the data word is checked to 
        see if it is valid (less than 1000 words). If it is not, the send 
        overflow flag will be set on. If the data size is acceptable, and 
        the command given was 0FF11H, the command integer array will be 
        copied to the send buffer. If the command given was 0FF15H, it is 
        assumed that the command was previously loaded into the send 
        buffer by the 0FF23H function. The Fryers driver will then take 
        over, and primary control is returned to the application so that 
        it can go about its business.

        3. Check the returned status in register AX for any transmission 
        errors. This check is done to verify that the send command was 
        correctly processed. 

        4. Wait for the transfer to complete. This is accomplished by 
        calling the packet status function 0FF13H and looking at the send 
        ready flag returned in AX. When the send ready flag goes on again 
        the command is finished. 

        5. Check to see if the command was properly processed. This can 
        be determined by looking at the receive ready flag. When on it 
        indicates that the command was processed and the response is 
        valid. 

        6. Read in and check the response for the desired command result 
        (function 0FF12H). This is done by looking at the first word in 
        the response array to find out what the response is.

        If the response is ACK, then the command was accepted. An Invalid 
        command response indicates that the command is not valid and 
        could not be processed. If data was requested, then the proper 
        response is the requested data. The correct response will be the 
        data request command with the high bit set. 





              Frye PC Communications Interface Definition    page 28

        Status, error, and control flags:

        The state control flags used to process the data transfer are 
        readable by the application program through the status function. 
        These flags can be used to monitor the transfer of data and 
        determine when a command may be sent and when a response is valid 
        and/or ready to be read.


        Status flags returned in register AL               (PIFLAGS low)

        0: Send ready       ;SNDRDY - Ready to accept send cmd

        1: Receive ready    ;RCVRDY - Data waiting in buffer to be read

        2: Send overrun     ;SNDOVR - New cmd given before old cmd sent

        3: Send overflow    ;SNDOVF - Data size given too large to send 

        4: Receive overrun  ;RCVOVR - New response overwrote old one

        5: Packet disabled  ;NOPKEN - Packet driver not enabled

        6: Link broken      ;NOPOLL - Poll synchronization has been lost

        7: Transfer error   ;TXEROR - Bad or no response from instrument 


        Error flags returned in register AH              (PIFLAGS high)

        0: Checksum error   ;CHKERR - Bad checksum receiving data

        1: Poll response    ;POLRSP - Poll request received as a response

        2: NAK response     ;NAKRSP - NAK received as a response

        3: Receive overflow ;RCVOVF - Received data too long for buffer

        4: Receive timeout  ;RCVTOT - Timeout receiving data

        5: Response timeout ;RSPTOT - Timeout waiting for response

        6: I/O error        ;IOEROR - Communications link failure.

        7: Retry timeout    ;RTYERR - Timeout on retrying to transfer












              Frye PC Communications Interface Definition    page 29

        Control flags returned in register CX                   (TXINFO)

        0: Poll sync        ;POLSYN - Receiving poll request sync packet

        1: Poll active      ;POLACT - Poll frame is active

        2: Sending packet   ;SNDPAK - Sending a packet

        3: Awaiting rsp     ;AWTRSP - Waiting for response packet

        4: Receiving rsp    ;RCVRSP - Receiving the response packet

        5: AutoBaud detect  ;AUTOBD - Baudrate error detected

        6: Auto terminate   ;AUTOQT - Quick Terminate active

        7: Transfer aborted ;PABORT - The transfer was aborted

        8: Baud sync seek   ;BDSEEK - Baudrate synchronization seek

        9: Packet flush     ;PKFLSH - Packet data stream flush

        10: Skip Poll       ;SKPOLL - Skip Poll Status flag

        11: Not used        ;-----  - <unknown>

        12: Not used        ;-----  - <unknown>

        13: Not used        ;-----  - <unknown>

        14: QT Failed       ;QTFAIL - Quick Terminate failed

        15: Send timeout    ;SENDTO - * Timeout while sending a packet

        Note: Prior to V4.00 only register CL had valid flags. 
        CH returned the transfer retry count. The definition changed in 
        version 4.00 to pick up the additional control flags needed.
        Bit flag 15 (SENDTO) does not happen in the 16bit driver. 
        Bit flag 14 (QTFAIL) is new with V4.10 and V5.10.


















              Frye PC Communications Interface Definition    page 30

        Uart error flags returned in register DL

        0: Port error       ;IOFAIL - Com port hardware/software failed
                                      (doesn't happen in 16bit)

        1: Overrun error    ;OVRERR - Old data was not read from uart
                                      (normally this can't happen)

        2: Parity error     ;PARERR - Incorrect parity received
                                      (not used - always returns zero) 

        3: Framing error    ;FRMERR - character synchronization was lost
                                      (can happen during autobaud search)

        4: Break detect     ;BRKDET - A break condition was detected
                                      (can happen during autobaud search)

        5: Transmit Error   ;TXFULL - Transmiter overflowed - data lost
                                      (doesn't happen in 16bit)

        6: Not used         ;-----  - <unknown>

        7: Not used         ;-----  - <unknown>

        Register DH contains the current driver state.
        Normally this will be 02H, but depending on the current activity 
        it can take on any number (odd numbers are not allowed in the 16 
        bit driver, but are valid in the 32 bit driver). The number 
        defines the state that will be entered for the next action by the 
        driver's state machine.

        Register BX returns a general purpose timer count. This value can 
        be set with the time-out set command. Once set the counter will 
        increment by one for every state tick in the driver. The default 
        is approximately 55 milliseconds per tick. This can be changed 
        with the 0FF07H and 0FF17H functions. Note that it is possible to 
        set the ASCII (non-packet) timer resolution different than the 
        packet timer resolution. In that case, the general purpose timer 
        will be incremented by the resolution set for the mode the driver 
        is in. This may cause confusion if you expect the timer to have 
        the same resolution in packet and non-packet (ASCII) modes.
















              Frye PC Communications Interface Definition    page 31


        History:  10/24/87 med
                  01/04/89 med
                  04/26/90 med   (v2.31 Fryers)
                  12/18/90 med   (v2.50 Fryers)
                  04/26/90 med   (v2.11 Fryers)
                  01/16/92 med   (revised documentation only)
                  11/16/92 med   (packet disable flag added)
                  10/07/93 med   (v3.21 Fryers - Quick terminate)
                  09/28/94 med   (v4.00 Fryers - autobaud change)
                  12/05/96 med   (v4.12 Fryers - 16bit rev)
                  07/31/97 med   (v5.00 Fryers - 32 bit DLL changes) 
                  11/20/97 med   (v5.15/v4.15 Fryers)
                  04/05/06 med   (revised documentation only)

        <end>

