Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output command process
Reexamination Certificate
1999-03-12
2002-02-26
Auve, Glenn A. (Department: 2181)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output command process
C710S120000
Reexamination Certificate
active
06351779
ABSTRACT:
FIELD OF THE INVENTION
The present invention pertains generally to instrument I/O drivers, and more particularly to a method and system for extending standard virtual instrument software architecture library functionality and reducing the overall latency time of executing multiple functions over an I/O bus.
BACKGROUND OF THE INVENTION
Remote control of instruments has become more widespread due in part to the availability of increased alternatives in high-speed data communication networks, including the proliferation of the internet. It is desirable in many industrial applications to be able to monitor and control instruments from a remote location. The configuration of a remote instrument control setup generally includes a computer system that runs a local instrument monitoring/control program which interfaces, over an I/O bus, with an I/O controller located within or at the instrument itself. Although communication between the computer system and I/O controller may be implemented in numerous ways using a variety of defined data packages, a standardized instrument I/O function library has been developed for the purpose of consistency across the instrumentation industry. This instrumentation standard is known as the VXI Plug&Play Systems Alliance, VPPP−4.3: The VISA Library.
The VISA library provides a number of low-level I/O functions, called primitives, for moving data words or blocks of data words to or from test and measurement instruments. These I/O functions are called by user application programs either directly, or indirectly through instrument drivers. Drivers and user applications that call the VISA I/O operations can be very portable, working on many hardware interfaces as well as different vendors' implementations of the VISA I/O libraries. For example, one vendor's version of VISA can be swapped with another vendor's VISA, yet the instrument drivers and applications do not need to be changed or recompiled. Several versions of VISA have been developed that comply with different I/O bus specifications, such as GPIB, embedded VXI, MXI, GPIB-VXI, IEEE 1394, RS-232, and LAN. VISA functions generate I/O instructions that are interpreted by some type of bus I/O interface (e.g., RS-232, GPIB, VXI controllers). The I/O interface interprets the I/O instructions to control various instruments that are connected to that particular interface.
VXI bus based instrument devices can operate very efficiently when controlled over fast, low-latency interfaces such as embedded VXI or MXI. They operate less efficiently when controlled over slower interfaces such as GPIB or RS-232, or higher-latency interfaces such as LAN or IEEE 1394.
Some VISA functions, including standard peek and poke functions which essentially read from and write to registers in the instrument, are meant to be high performance operations. In some very high speed busses such as embedded VXI, the latency between initiation of a peek or poke function and the completion of the peek or poke function, is very low—on the order of less than 10 microseconds. However, on slow busses such as the IEEE 1394 “Firewire” bus, the bus latency per instruction is more on the order of approximately 150 to 200 microseconds. The high latency of slower busses becomes quite visible when a number of peeks and/or pokes are executed in sequence. For example, the execution of ten sequential peeks and/or pokes results in a latency of approximately 100 microseconds on the embedded VXI versus approximately 1.5 to 2.0 milliseconds using the IEEE 1394 bus. Accordingly, for multiple VISA I/O function calls, it is clear that the bus latency significantly affects the overhead for each function call, thereby significantly increasing the overall time and cost of remote interfacing with the instrument when using a high-latency bus.
Bus latency can be even more problematic. Many applications and instrument drivers depend on certain low-level functions such as peek and poke operations being very fast. In these instances, the use of a high-latency bus may even render the application unusable. For example, often an application must wait on the status of a register bit changing before continuing. The poll of the bit is typically implemented by performing a peek on the register, masking the returned value with a bit mask, and comparing the bit value with a compare value. The poll is repeated, resulting in a sequence of peek function calls, until the bit changes to the bit compare value. If the bit change is used to trigger a time-critical function on the user's end, the return status on the peek commands may not be fast enough to trigger the user's time-critical function, and thus the application cannot work with the underlying I/O bus. Accordingly, a need exists for a method for decreasing the overall latency of executing multiple sequential I/O function calls in a system with a high latency bus.
As described previously, the current VISA library provides only low-level functions. All high-level functions to be performed by an application must be built from each of these low-level functions. For standard high-level functions that are consistently repeated throughout an application or that are used in many different applications, the repeated implementation of these higher-level functions can be quite burdensome in terms of application and/or instrument driver code size and implementation/debug time. One potential implementation would be for each vendor to simply add new functions to their version of the standard VISA library. This is problematic, however, because it requires instrument drivers to check that this particular vendor's standard VISA library is installed and requires it to perform runtime checking—that is, if the vendor's standard VISA library is installed, it makes calls to the extended functions; otherwise it decodes the extended functions into standard VISA primitives and makes calls only to those standard VISA primitives. Accordingly, a need exists for a method for extending the function set of a standard I/O library, such as the standard VISA library, in order to generate higher-level functions at the I/O library level without causing compatibility problems with versions of the standard I/O library that do not support extended functions.
SUMMARY OF THE INVENTION
In accordance with the invention, an extension library is provided which solves the above-mentioned problems. In particular, the extension library provides functions which allow a user application or instrument driver to queue multiple sequential I/O library functions into a single package for transmission across the I/O bus. For I/O libraries that support the extended functions, this allows the overhead due to bus latency to be reduced to that of a single I/O bus instruction. As used herein, the term I/O bus instruction is the set of signals associated with a single I/O function sent across the I/O bus for interpretation by the I/O controller. For example, the set of signals required to instruct the I/O controller to invoke a poke function in the instrument is considered a single I/O bus instruction. As another example, the set of instructions required to perform a block move function (which is used to send a data package) is considered a single I/O bus instruction. Once the multiple function package arrives at the I/O controller over the I/O bus, the controller can perform the queued functions contained in the package very quickly in sequence.
The extension library also allows the primitive standard I/O libraries to be extended to include higher-level functions without affecting the compatibility and portability of user applications and instruction drivers with the underlying standard I/O library. When a call is made to an extended function in the extension library, the extended function detects whether the I/O interface, including the underlying I/O library and I/O controller, supports the extended function. If the underlying I/O interface does support the extended function, the extended function simply passes the extended function call on
Berg Nathan
Hammer Leslie P.
Hill Gregory A
Platz Charles
Agilent Technologie,s Inc.
Auve Glenn A.
LandOfFree
Extension library to standard visa library for support of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Extension library to standard visa library for support of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Extension library to standard visa library for support of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2968984