Name: Nathan Berg
Ballot Number: 53268
Date: July 12, 1999
Regarding the proposed "IEEE Std 488.1-1992/D1.2 Draft Standard for a Higher Performance IEEE 488.1". The italicized comments indicate the changes needed to change my vote to ‘approve’.
Section 5.7 of the current IEEE 488.1-1987 spec deals with how instruments should behave when an unrecognized universal command is received. This is not, however, a requirement, and thus there is no guarantee about how an instrument will behave when an unrecognized universal command is received. This implies that adding new universal commands to the 488.1 spec can cause compatibility problems with existing instruments, ranging from simple instrument problems to catastrophic system failures.
Section 4.14 of the proposed specification adds several new interface functions to the original 488.1-1987 spec associated with the Configuration Interface function.
Section 4.14 should be removed
The 488.1-1987 specification has mechanisms in place to allow a controller to reliably interrupt a data transfer. The controller can then perform other necessary work (such as serial poll a device), and resume the interrupted data transfer. This interrupted data transfer is guaranteed to have not compromised the integrity of the data despite the interruption.
However, when a non-interlocked transfer is in progress, there is no way for a controller in each of the 3 possible states (as an AHE, as a SHE, or as neither) to reliably interrupt that data transfer.
Provide mechanisms for controllers to interrupt a non-interlocked data transfer reliably (with no data loss or corruption), whether the controller is a source, an acceptor, or neither.
Section 7.2.4 of the proposed spec mentions that "If the SHE and AHE functions are used to transfer data with non-interlocked handshake cycles, all guidelines of section 7.2.3 should be followed". First, this reads ‘should be’, not ‘shall be’, so it is a strong recommendation, not a requirement. Yet there is no discussion of how system performance or data integrity is affected when these guidelines are not met. Many systems have devices that do not meet the specifications outlined in 7.2.3, but rather follow the guidelines in 7.2.1 or 7.2.2. Simply having one of these devices connected could cause problems with non-interlocked data transfers
A comprehensive discussion is needed of how performance and data integrity is affected when devices are included in a system that conform to either section 7.2.1 or 7.2.2 but not 7.2.3.
488.1 has been a widely used standard for over 20 years. Any changes to this standard must be accompanied by a comprehensive study of cross-vender interoperability. I do not believe that enough multi-vendor testing has been accomplished at this time to make such substantial changes to such an established specification.
Publish the results of extensive and comprehensive multi-vendor system testing