David Clemens
July 21, 1999
Ballot Number 52822
IEEE Project 488.1/D1.2
Unfortunately, I am voting with a NEGATIVE (against) the proposed IEEE Project 488.1/D1.2 for the following reasons:
Backward Compatibility is Not Ensured
The ANSI/IEEE 488.1-1987 standard specifically prohibits the
addition of new interface functions. Specifically, the last
sentence of ANSI/IEEE 488.1-198 Section 5.1 System Compatibility
reads "In order to provide system compatibility a designer
shall not introduce new interface functions beyond those designed
in Section 2".
The proposed draft violates this statement by adding the CF (Configuration) function as indicated in Table 1 Section 4.1.2.3 Interface function repertoire. The draft standard also adds the SHE and AHE interface functions.
Existing instruments compliant with IEEE 488.1-1987 may face compatibility problems with the new interface functions. No specification exists (nor can logically exist) for prediction of system behavior when the CF, SHE, and AHE functions are encountered with existing implementations. Existing implementations have unknown results when they encounter these new functions.
The CF, SHE, and AHE functions must be removed from the draft standard. This includes "section 4.14 Configuration (CF) interface function"
Cable Length Parameter – Usage Problems
Exposing the cable length parameters adds additional
complexity to the user and systems integrators. A user adding an
instrument to an existing system might very easily forget to
update the cable length parameter. Is there a mechanism that can
be added to the standard to hide the cable length from the
application? This must be added to the standard to remove
potential errors.
If this is not possible, then a mechanism needs to be added to ensure that the cable length is correct. System performance and data integrity are dependent on correct definition of cable length.
Finally, if the cable length needs to be added, then a mechanism for communicating with the controlling I/O software needs to be documented. The cable length parameter is a piece of information that is needed by the controlling I/O software. A standard mechanism should be specified for transferring that information to the controlling software.
Divergence from IEC 625
Historically, both IEEE 488.1 and IEC 60625-1 has been
consistent (identical). This has benefited users by having both
standards the same, thus eliminating confusion from regional
differences in standard subscriptions in the rest of the world.
The IEC through the IEC SC65C/WG3 has indicated that it
disapproved of the proposed changes and indicated several serious
technical flaws that have not been addressed. It would be highly
beneficial to the worldwide users of 488 for the two standards to
remain consistent (identical). If this ballot is passed, it will
most likely cause instruments to be developed with the IEEE 488
standard to be incompatible with the IEC 60625-1 standard. The
working groups must resolve differences and maintain a consistent
standard.
Interoperability Testing
It is a given that, for such a widely used and accepted
international standard such as 488, a thorough, public, and well-documented
verification of compatibility with both existing and potential
applications be implemented and published. Results of such
investigations must also be submitted with ballots of this nature
to ensure a thorough examination of potential adverse
consequences due to such serious proposed changes.
Has there been sufficient multi-vendor interoperability testing with the proposed standard? I would like to see these results shared in a public forum.
In addition, I would have to believe that any "testing" that may have been completed would not be representative of a true-multivendor solution. Hearsay has it that multiple products from different vendors were shown to be "interoperable". However, all of these products were based on one company’s proprietary implementation. This does not provide evidence that multiple vendors can implement the standard, nor does it provide evidence that other vendors are willing or interested in providing such a complex solution. Further, since the CF interface function adds substantial complexity, it is highly probable that another vendor would create an incompatible version. This would cause user confusion, frustration, and potentially serious application results.