GPIB system and method which provides asynchronous event notification

Abstract

A GPIB system which includes asynchronous event notification. The GPIB application first provides a notify request to GPIB driver level software, preferably an ibnotify call or a GPIB Notify OLE control. The notify request includes a unit descriptor which uniquely identifies the GPIB device, event information regarding a plurality of GPIB events to monitor, a reference to a callback function in the GPIB application, and user defined reference data for the callback function. In response to the notify request, the GPIB driver level software begins monitoring events specified by the event information. When an event occurs which is being monitored, the GPIB driver level software recognizes the event and invokes the callback function. The invocation of the callback function is performed asynchronously to the GPIB application. The callback function may include one or more calls to one or more functions in the GPIB driver software. The callback function also uses the user defined reference data to aid in handling the event.

Claims

We claim:

1. A method of asynchronously notifying a GPIB application when one or more GPIB events occur in a GPIB system, wherein the system comprises the GPIB application which interfaces through GPIB driver software to a GPIB device, wherein the GPIB application and the GPIB driver software execute on a computer system, the method comprising:

receiving an asynchronous notify request from the GPIB application, wherein the asynchronous notify request includes a unit descriptor, event information regarding a plurality of GPIB events to monitor, and a reference to a callback function in the GPIB application, wherein the unit descriptor uniquely identifies the GPIB device; and

monitoring events specified by said event information, wherein said monitoring is performed in response to said receiving said asynchronous notify request, wherein said events comprise state changes of the GPIB device identified by the unit descriptor;

determining that an event specified by said event information has occurred;

invoking said callback function in response to said determining that said event has occurred, wherein said invocation is performed asynchronously to the GPIB application.

2. The method of claim 1, wherein said callback function includes one or more calls to one or more functions in the GPIB driver software, the method further comprising:

executing said callback function to handle the event, wherein said callback function invokes said one or more functions in the GPIB driver software.

3. The method of claim 2, wherein the asynchronous notify request further includes user defined reference data for said callback function;

wherein said executing said callback function to handle the event includes using said user defined reference data.

4. The method of claim 1, further comprising:

configuring the GPIB driver software to use interrupts prior to receiving the asynchronous notify request from the GPIB application;

said event occurring;

generating an interrupt in response to said event occurring wherein said determining that an event specified by said event information has occurred includes:

receiving the interrupt indicating that said event has occurred; and

asynchronously notifying the GPIB application of said event.

5. The method of claim 1, wherein said event information comprises a bit mask, wherein said bit mask specifies said plurality of GPIB events to monitor, wherein said bit mask includes a plurality of bits, wherein each of said plurality of bits represents one of said GPIB events to monitor;

wherein said monitoring comprises monitoring events identified by said bits in said bit mask.

6. The method of claim 5, the method further comprising:

executing said callback function to handle the event, wherein said callback function returns a mask value; and

rearming said event information with said mask value returned by said callback function;

wherein said monitoring events, determining that an event specified by said event information has occurred, and invoking said callback are repeated using said mask value returned by said callback function.

7. The method of claim 5, wherein said plurality of GPIB events to monitor include a timeout event;

wherein said bit mask includes a timeout bit, wherein said timeout bit is set to indicate monitoring of said timeout event;

when said timeout event occurs when a timeout period has elapsed.

8. The method of claim 1, wherein the GPIB device is a GPIB interface board comprised in the computer system, wherein the events comprise: TIMO, END, SRQI, CMPL, LOK, REM, CIC, ATN, TACS, LACS, DTAS, and DCAS.

9. The method of claim 1, wherein the GPIB device is a GPIB instrument coupled to the computer system, wherein the events comprise: TIMO, END, RQS, and CMPL.

10. The method of claim 1, wherein said monitoring events, determining that an event specified by said event information has occurred, and invoking said callback function are performed by the GPIB driver software.

11. The method of claim 10, wherein the GPIB application does not check the status of the GPIB device the GPIB driver software monitoring events.

12. The method of claim 1, further comprising:

beginning an asynchronous I/O operation;

receiving a notify request from the GPIB application after beginning the asynchronous I/O operation; and

resynchronizing the GPIB driver level software in response to receiving the notify request.

13. The method of claim 1, wherein said notify request comprises an OLE control.

14. A GPIB system which asynchronously notifies a GPIB application when one or more GPIB events occur in the GPIB system, the GPIB system comprising:

a computer system comprising a CPU and memory, wherein the memory stores the GPIB application and GPIB driver software, wherein the GPIB application and the GPIB driver software execute on the computer system; and

a GPIB device coupled to the computer system,

wherein the GPIB application interfaces through the GPIB driver software to the GPIB device;

wherein the GPIB application executing on the computer system is operable to provide an asynchronous notify request to the GPIB driver software, wherein the asynchronous notify request includes a unit descriptor, event information regarding a plurality of GPIB events to monitor, and a reference to a callback function in the GPIB application, wherein the unit descriptor uniquely identifies the GPIB device;

wherein the GPIB driver software executing on the computer system is operable to monitor events specified by said event information in response to the asynchronous notify request, wherein said events comprise state changes of the GPIB device identified by the unit descriptor;

wherein the GPIB driver software executing on the computer system is operable to determine that an event specified by said event information has occurred and is operable to invoke said callback function in response to determining that said event has occurred, wherein said invocation is performed asynchronously to the GPIB application.

15. The GPIB system of claim 14, wherein said callback function includes one or more calls to one or more functions in the GPIB driver software;

wherein said callback function invokes said one or more functions in the GPIB driver software.

16. The GPIB system of claim 15, wherein the asynchronous notify request further includes user defined reference data for said callback function;

wherein said callback function uses said user defined reference data during execution.

17. The GPIB system of claim 14, wherein said event information comprises a bit mask, wherein said bit mask specifies said plurality of GPIB events to monitor, wherein said bit mask includes a plurality of bits, wherein each of said plurality of bits represents one of said GPIB events to monitor.

18. The GPIB system of claim 14, wherein the GPIB device is a GPIB interface board comprised in the computer system, wherein the events comprise: TIMO, END, SRQI, CMPL, LOK, REM, CIC, ATN, TACS, LACS, DTAS, and DCAS.

19. The GPIB system of claim 14, wherein the GPIB device is a GPIB instrument coupled to the computer system, wherein the events comprise: TIMO, END, RQS, and CMPL.

20. A memory media which stores program instructions for asynchronously notifying a GPIB application when one or more GPIB events occur in a GPIB system, wherein the system comprises the GPIB application which interfaces through GPIB driver software to a GPIB device, wherein the GPIB application and the GPIB driver software execute on a computer system, wherein the program instructions are executable to implement the steps of:

receiving an asynchronous notify request from the GPIB application, wherein the asynchronous notify request includes a unit descriptor, event information regarding a plurality of GPIB events to monitor, and a reference to a callback function in the GPIB application, wherein the unit descriptor uniquely identifies the GPIB device;

monitoring events specified by said event information, wherein said monitoring is performed in response to said receiving said asynchronous notify request, wherein said events comprise state changes of the GPIB device identified by the unit descriptor;

determining that an event specified by said event information has occurred; and

invoking said callback function in response to said determining that said event has occurred, wherein said invocation is performed asynchronously to the GPIB application.

Description

FIELD OF THE INVENTION

The present invention relates to GPIB driver level software, and more particularly to a method for providing asynchronous event notification in a GPIB system.

DESCRIPTION OF THE RELATED ART

The IEEE 488 bus, also referred to as the General Purpose Instrumentation Bus (GPIB), is used for connecting instruments and controllers to a common bus to perform various test and measurement functions. A typical GPIB system comprises one or more GPIB instruments, up to 14 instruments, and a controller, typically a GPIB interface board installed in a general purpose computer, connected by standard GPIB cables. A GPIB software application executes on the computer to control the instruments. The GPIB application interfaces through GPIB driver level software to the GPIB controller.

In response to the GPIB application, the controller provides program commands to the instruments, and the instruments return formatted data and response messages to the controller. GPIB instruments are message-based devices which are programmed with high-level ASCII character strings. A respective GPIB device includes a local processor that parses the command strings and sets the appropriate register bits to perform the indicated functions.

The original ANSI IEEE 488 standard, now referred to as IEEE 488.1, was introduced in 1975 and greatly simplified the interconnection of programmable instruments by clearly defining mechanical, electrical and hardware protocol specifications. This enabled users to connect instruments from different manufacturers to a standard cable, thus allowing the instruments to communicate with each other. The original IEEE 488.1 standard dramatically improved the productivity of test engineers. However, this original standard included a number of limitations. More specifically, the IEEE 488.1 standard did not specify data formats, status reporting guidelines, a message exchange protocol, configuration commands, or a minimum set of device commands. As a result, different manufacturers implemented each item differently, resulting in integration problems for the test system developer.

In 1987, a new IEEE 488 standard for programmable instruments and devices was approved which strengthened the original IEEE 488.1 standard by precisely defining how controllers and instruments communicated with each other. The IEEE 488.2 standard kept the IEEE 488.1 standard completely intact while also defining standard data codes and formats, a status reporting model, a message exchange protocol, a set of common commands for all instruments, and controller requirements, therefore making systems more compatible and simplifying program development. In general, the IEEE 488.2 standard focuses on software protocol issues while the IEEE 488.1 standard is primarily hardware oriented.

Thus the ANSI/IEEE Standard 488.1-1987, also known as GPIB (General Purpose Interface Bus), describes a standard interface for communication between instruments and controllers from various vendors. The IEEE 488.1 standard contains information about electrical, mechanical, and functional specifications. The GPIB is a digital, 8-bit parallel communications interface with data transfer rates of 1 Mbytes/s and above, using a 3-wire handshake. The bus supports one System Controller, usually a computer, and up to 14 additional instruments. The ANSI/IEEE Standard 488.2-1992 extends IEEE 488.1 by defining a bus communication protocol, a common set of data codes and formats, and a generic set of common device commands.

As noted above, a GPIB system includes GPIB driver level software which interfaces between a GPIB application and the GPIB hardware. The de facto standard for GPIB driver level software are the NI-488 and NI-488.2 software architectures, collectively referred to as the NI-488 software architecture, which is available in the NI-488 and NI-488.2 driver software products available from National Instruments. The NI-488 software architecture includes an Application Programming Interface (API) which allows the GPIB application to call or invoke functions in the GPIB driver level software to communicate with the GPIB hardware. In other words, the GPIB driver level software handles the details of communication, ie., the transfer of commands and data, over the GPIB connection between the computer and the GPIB instruments. GPIB driver level software has traditionally been required to poll a device to determine when an event occurs. This typically requires a large amount of unnecessary processor time, thus consuming value CPU resources. Therefore, a system and method is desired for providing asynchronous event notification in a GPIB system.

SUMMARY OF THE INVENTION

The present invention comprises a system and method which provides asynchronous event notification in a GPIB system. The method operates to asynchronously notify a user when one or more GPIB events occur in the GPIB system. The GPIB system comprises a GPIB application which interfaces through GPIB driver software to a GPIB device, wherein the GPIB application and the GPIB driver software execute on a computer system.

The method comprises first receiving a notify request from the GPIB application. The notify request is preferably an ibnotify call or a GPIB Notify OLE control. The notify request includes a unit descriptor which uniquely identifies the GPIB device, event information regarding a plurality of GPIB events to monitor, a reference to a callback function in the GPIB application, and user defined reference data for the callback function.

In response to the notify request, the GPIB driver level software begins monitoring events specified by the event information. The events comprise state changes of the GPIB device identified by the unit descriptor. When an event occurs which is being monitored, an interrupt is generated and provided to the GPIB driver level software. In response to the received interrupt, the GPIB driver level software determines that an event specified by the event information has occurred. The GPIB driver level software then invokes the callback function in response to determining that the event has occurred. According to the present invention, the invocation of the callback function is performed asynchronously to the GPIB application.

The callback function may include one or more calls to one or more functions in the GPIB driver software. In this case, when the callback function is executed to handle the event, the callback function invokes the one or more functions in the GPIB driver software. The callback function also uses the user defined reference data to aid in handling the event.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:

FIG. 1 illustrates a GPIB instrumentation system;

FIG. 2 illustrates the software architecture of the GPIB instrumentation system;

FIG. 3 is a flowchart diagram illustrating operation of the GPIB driver level software performing asynchronous event notification;

FIG. 4 illustrates the Custom Controls dialog box used for adding the GpibNotify OLE control to the toolbox;

FIG. 5 illustrates a Notify icon added to Toolbox; and

FIG. 6 illustrates a GpibNotify OLE control being placed on a Visual Basic form.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Incorporation By Reference

The IEEE 488.1 specification and the IEEE 488.2 specification published by the IEEE are both hereby incorporated by reference in their entirety.

The NI-488 and NI-488.2 reference manuals, available from National Instruments Corporation, are hereby incorporated by reference in their entirety.

FIG. 1--GPIB Instrumentation System

Referring now to FIG. 1, a GPIB instrumentation control system 100 is shown. The system 100 comprises a computer 102 which connects to one or more GPIB instruments. The computer 102 comprises a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 102 connects to one or more GPIB instruments 112 to analyze, measure or control a unit under test (UUT) or process 130.

The GPIB instrument 112 is coupled to the computer 102 via a GPIB interface card 122 provided by the computer 102. The GPIB card 122 is typically plugged in to an I/O slot in the computer 102, such as a PCI bus slot, a PC Card slot, or an ISA, EISA or MicroChannel bus slot provided by the computer 102. However, the GPIB interface card 122 is shown external to computer 102 for illustrative purposes. It is noted that various other types of instruments may be comprised in the instrumentation system 100, such as a data acquisition board, a VXI instrument, or a serial instrument.

The GPIB instruments are coupled to the unit under test (UUT) or process 130, or are coupled to receive field signals, typically generated by transducers. The system 100 may be used in a data acquisition and control application, in a test and measurement application, a process control application, or a man-machine interface application, among others.

The computer 102 preferably includes a memory media, such as a magnetic media, CD-ROM, or floppy disks 104. The memory media preferably stores a multi-threaded GPIB application and also stores GPIB driver level software according to the present invention. The present invention comprises GPIB driver level software according to the present invention stored on a memory and/or hard drive of the computer 102 and executed by a CPU of the computer 102. The GPIB driver level software operates to enable asynchronous event notification in a GPIB system. The CPU executing code and data from the memory thus comprises a means for allowing asynchronous event notification in a GPIB system according to the steps described below.

FIG. 2--GPIB Software Architecture

Referring now to FIG. 2, the software architecture for a GPIB instrumentation system is shown. As shown, the software architecture comprises a GPIB application program which interfaces through GPIB driver level software to one or more GPIB instruments.

The top level of the software architecture typically comprises a GPIB application program used for high level control of the GPIB instrument(s). The GPIB application program may operate in conjunction with one or more instrument drivers to interface through the GPIB driver level software to the GPIB instruments. The GPIB application program may be created with various development platforms, such as the LabVIEW graphical programming language or the LabWindows.backslash.CVI interactive C development environment. These software development environments include fully integrated GPIB libraries for instrument control. The GPIB application makes calls to various functions in the GPIB driver level software to communicate with the GPIB hardware.

The GPIB driver level software interfaces the commands or function calls in the GPIB application to the actual GPIB interface. In other words, in response to function calls made by the application, the GPIB driver level software communicates with the GPIB controller to control the GPIB instruments. The GPIB driver level software thus handles the details of communication, i.e., the transfer of commands and data, over the GPIB connection between the computer and the GPIB instruments. As discussed in the background section, the de facto standard for GPIB driver level software is the NI-488 software architecture available from National Instruments. The NI-488 software architecture includes an Application Programming Interface (API) which allows the GPIB application to call or invoke functions in the GPIB driver level software to communicate with the GPIB hardware.

As discussed above, the GPIB hardware comprises a GPIB interface card, typically a plug-in card to a personal computer, which couples through the GPIB to the one or more GPIB instruments.

Synchronous Event Notification

In many GPIB applications, GPIB events are used to monitor system status or respond to instruments that are requesting service. Traditional methods for responding to GPIB events involve synchronous waits on the events of interest or polling loops that periodically check the GPIB status variable, ibsta, for the events of interest.

Asynchronous Event Notification

According to the present invention, GPIB applications can asynchronously receive event notification using one of two mechanisms, these being the ibnotify function, or the GpibNotify OLE control. Asynchronous callback functions offer a new approach for automatically executing blocks of code when one or more GPIB events are detected. Using the ibnotify, or the GpibNotify ActiveX (OLE), function and the asynchronous event notification technique, applications can eliminate wasted processing time associated with using synchronous waits or the polling technique.

Asynchronous event notification is useful where the user desires the GPIB application to be notified asynchronously about the existence of one or more GPIB events. For example, asynchronous event notification can be used where the GPIB application only needs to interact with the GPIB device when it is requesting service. After setting up for event notification, the application does not need to check the status of the GPIB device. When the GPIB device requests service, the GPIB driver automatically notifies the application that the event has occurred by invoking a callback function. The callback function is registered as part of the original GPIB event notification request.

In the preferred embodiment, both board-level and device-level GPIB events are supported. For device-level events, both ibnotify and GpibNotify take a device handle and a mask that can contain the following GPIB event bits: RQS, CMPL, END, or TIMO. For board-level events, both ibnotify and GpibNotify take a board handle and a mask that can contain any GPIB event bits except RQS or ERR. It is noted that the mask bits are identical to the ibwait mask bits. In the example of waiting for the GPIB device to request service, the user may desire to pass a mask with RQS (for device-level) or SRQI (for board-level). The user-defined callback function that is registered is invoked by the GPIB driver when one or more of the mask bits are TRUE.

For more information on usage, please refer to either the ibnotify Usage or the GpibNotify Usage sections below. For more specific information about ibnotify or the GpibNotify OLE control, please refer to the ibnotify/GpibNotify function definition below.

Benefits of Asynchronous Callback Functions

In basic GPIB communication, a command is written to the device and then the response is read back. Both of these operations are generally performed synchronously with the read following the write. However, many times, devices may require a period of time to take measurements and prepare a response to a given query. When this is the case, processor time is wasted if the application simply calls a synchronous GPIB write and then waits until the response is available to do a read operation.

For example, consider the following sequence of function calls:

    ______________________________________
    ibwrt(ud, command, count)
                   Write a Command
    ibwait(ud, RQS)
                   Wait For the Device To Request Service
    ibrd(ud, data, count)
                   Read The Data
    ______________________________________

    ______________________________________
    ibwrt(ud, command, count);
                   Write a Command
    while (!(ibsta & RQS)) {
                   End Loop If Device Requested Service
    Other Processing Do Other Program Tasks
    ibwait(ud,0);  Check For Device Requesting Service
     }
    ibrd(ud,count);  Read The Data
    ______________________________________

    ______________________________________
    Input for ibnotify:
    ud        Unit descriptor
    mask      Bit mask of GPIB events to notice
    Callback  Pointer to the callback function (see prototype below)
    RefData   User-defined reference data for the callback
    Output for ibnotify:
    Function Return
              The value of ibsta
    ______________________________________

    ______________________________________
    Notify Mask Layout
    Mnemonic
           Bit Pos Hex Value
                            Description
    ______________________________________
    TIMO   14      4000     Use the timeout period (see ibtmo) to
                            limit the notify period
    END    13      2000     END or EOS is detected
    SRQI   12      1000     SRQ is asserted (board only)
    RQS    11      800      Device requested service (device only)
    CMPL   8       100      I/O is complete (board only)
    LOK    7       80       GPIB board is in Lockout State (board
                            only)
    REM    6       40       GPIB board is in Remote State (board
                            only)
    CIC    5       20       GPIB board is CIC (board only)
    ATN    4       10       Attention is asserted (board only)
    TACS   3       8        GPIB board is Talker (board only)
    LACS   2       4        GPIB board is Listener (board only)
    DTAS   1       2        GPIB board is in Device Trigger State
                            (board only)
    DCAS   0       1        GPIB board is in Device Clear State
                            (board only)
    ______________________________________

    ______________________________________
    Callback Parameters
    ______________________________________
    LocalUd     Board or device descriptor
    LocalIbsta  Value of ibsta
    LocalIberr  Value of iberr
    LocalIbcntl Value of ibcntl
    RefData     User-defined reference data for the callback
    ______________________________________

    ______________________________________
    Input for the GpibNotify OLE Control
    ______________________________________
    ud            Unit descriptor
    mask          Bit mask of GPIB events to notice
    ______________________________________

    ______________________________________
    Output for the GpibNotify OLE Control:
    ______________________________________
    Function Return     The value of ibsta
    ______________________________________

    ______________________________________
    Callback Parameters
    ______________________________________
    LocalUd      Board or device descriptor
    LocalIbsta   Value of ibsta
    LocalIberr   Value of iberr
    LocalIbcntl  Value of ibcntl
    RearmMask    Bit mask of the GPIB events to notice next
    ______________________________________

    ______________________________________
    ibnotify   (
    int ud, //unit descriptor
    int mask,   //bit mask of GPIB events
    GpibNotifyCallback.sub.-- t Callback,   //callback function
    void *RefData//user-defined reference data
    ______________________________________

    ______________________________________
    int.sub.-- stdcall MyCallBack   (
    int LocalUd,
              //unit descriptor
    int LocalIbsta,
              //ibsta value
    int LocalIberr,
              //iberr value
    long LocalIbcntl,
              //ibcntl value
    void *RefData
              //user-defined reference data
    ______________________________________

    __________________________________________________________________________
    int.sub.-- stdcall MyCallback (int ud, int LocalIbsta, int LocalIberr,
         long LocalIbcntl, void *RefData);
    int ReadingsTaken=0;
    float Readings[1000];
    BOOL DeviceError=FALSE;
    char expectedResponse=0.times.43;
    int main( )
         int ud;
         //Assign a unique identifier to the device and store it in the
         //variable ud.ibdev opens an available device and assigns it to
         //access GPIBO with a primary address of 1, a secondary address of
         0,
         //a timeout of 10 seconds, the END message enabled, and the EOS
         mode
         //disabled. If ud is less than zero, then print an error message
         //that the call failed and exit the program.
         ud=ibdev
               (0,
                  //connect board
               1, //primary address of GPIB device
               0, //secondary address of GPIB device
               T10s,
                  //10 second I/O timeout
               1, //EOT mode turned on
               0);
                  //EOS mode disabled
    if (ud<0) {
            printf ("ibdev failed..backslash.n");
            return 0;
    }
    //Issue a request to the device to send the data. If the ERR bit
    //is set in ibsta, then print an error message that the call failed
    //and exit the program.
    ibwrt (ud, "SEND DATA", 9L);
    if (ibsta & ERR) {
            printf ("unable to write to device..backslash.n");
            return 0;
    }
    //set up the asynchronous event notification on RQS
    ibnotify (ud, RQS, MyCallback, NULL);
    if (ibsta & ERR) {
            printf ("ibnotify call failed..backslash.n");
            return 0;
    }
    while ((ReadingsTaken<1000)&&!(DeviceError)) {
            //Your application does useful work here. For example, it
            //might process the device readings or do any other useful work.
    }
    //disable notification
    ibnotify (ud, 0, NULL, NULL);
    //Call the ibonl function to disable the hardware and software.
    ibonl (ud, 0);
    return 1;
    }
    int.sub.-- stdcall MyCallback (int LocalUd, int LocalIbsta, int
    LocalIberr,
            long LocalIbentl, void *RefData)
    {
    char SpollByte;
    char ReadBuffer[40];
    //If the ERR bit is set in LocalIbsta, then print an error message
    //and return.
    if (LocalIbsta & ERR) {
            printf ("GPIB error %d has occurred. No more callbacks..backslash.
            n",
               LocalIberr);
            DeviceError=TRUE;
            return 0;
    }
    //Read the serial poll byte from the device. If the ERR bit is set
    //in ibsta, then print an error message and return.
    LocalIbsta=ibrsp (LocalUd, &SpollByte);
    if (LocalIbsta & ERR) {
            printf ("ibrsp failed. No more callbacks..backslash.n");
            DeviceError=TRUE;
            return 0;
    }
    //If the returned status byte equals the expected response, then
    //the device has valid data to send; otherwise it has a fault
    //condition to report.
    if (SpollByte !=expectedResponse) {
            printf("Device returned invalid response. Status
            byte=0x%x.backslash.n",
               SpollByte);
            DeviceError=TRUE;
            return 0;
    }
    //Read the data from the device. If the ERR bit is set in ibsta,
    //then print an error message and return.
    LocalIbsta=ibrd (LocalUD, ReadBuffer, 40L);
    if (LocalIbsta & ERR) {
            printf ("ibrd failed. No more callbacks..backslash.n");
            DeviceError=TRUE;
            return 0;
    }
    //Convert the data into a numeric value.
    sscanf (ReadBuffer, "%f", &Readings[ReadingsTaken]);
    ReadingsTaken+=1;
    if (ReadingsTaken>=1000) {
            return 0;
    }
    else {
    //Issue a request to the device to send the data and rearm
            //callback on RQS.
            LocalIbsta=ibwrt (LocalUD, "SEND DATA", 9L);
            if (LocalIbsta & ERR) {
               printf ("ibwrt failed. No more callbacks..backslash.n");
               DeviceError=TRUE;
               return 0;
            }
            else {
               return RQS;
            }
    }
    }
    __________________________________________________________________________

    __________________________________________________________________________
    Visual Basic Example
    __________________________________________________________________________
    Visual Basic Private Sub Form.sub.-- Load()
    ' Assign a unique identifier to the device and store
    ' it in the variable ud. ibdev opens an available
    ' device and assigns it to access GPIB0 with a primary
    ' address of 2, a secondary address of 0, a timeout of
    ' 10 seconds, the END message enabled, and the EOS
    ' mode disabled. If us id less than zero, then print
    ' an error message that the call failed and exit
    ' the program.
    Call ibdev(0, 2, 0, T10s, 1, 0, ud)
    If (ud < 0) Then
    MsgBox "ibdev error. I'm quitting!", 16
    End
    End If
    ' Install the GpibNotify callback mechanism for the OLE
    ' Control by calling its SetupNotify Procedure with an
    ' event mask for the RQS Event.
    GpibNotify1.SetupMask = RQS
    GpibNotify1.SetupNotify ud
    ' Check to see if there was an error invoking the GpibNotify Callback
    mechanism.
    If (TreadIbsta() And EERR) Then
    msg$ = "Error invoking Notification for RQS! ibsta = &H" +
            Hex$(ThreadIbsta())
    MsgBox msg$, vbCritical, "GPIB Notification Error!"
    msg$ = "iberr = " + Str$(ThreadIberr())
    MsgBox msg$, vbCritical, "GPIB Notification Error!"
    ' Call the ibon1 function to disable the hardware and software.
    Call ibon1(ud, 0)
    End
    End If
    If (ThreadIbsta() And &H4000) Then
    MsgBox ("Notification for RQS timed out.")
    End
    End If
    ' Write a command to the instrument to generate data and
    ' assert the SRQ line when the data is available.
    wrtbuf$ = "SEND DATA"
    Call ibwrt(ud, wrtbuf$)
    If (ibsta And EERR) Then
    MsgBox ("ibwrt Error!")
    ' Call the ibon1 function to disable the hardware and software.
    Call ibon1(ud, 0)
    End
    End If
    End Sub
    Private Sub GpibNotify1.sub.-- Notify(ByVal LocalUd As Long, ByVal
    LocalIbsta As Long,
    By Val LocalIberr As Long, ByVal LocalIbcntl As Long, RearmMask As Long)
    ' This is the user-defined callback routine that
    ' gets invoked when one or more GPIB events in the
    ' mask that is passed to the SetupNotify method occurs.
    ' For this sample program, a data point will be read and
    ' displayed from the device.
    Dim SPollByte As Integer
    ' If ERR bit is set in LocalIbsta that is passed into
    ' this subroutine, then print an error message and
    ' exit the function.
    If LocalIbsta And EERR Then
    MsgBox "Error with GPIB Notify #1-No more callbacks.", 16
    Exit Sub
    End If
    ' NOTE:   for the rest of this subroutine, the global
    '   version of ibsta is used when checking to see
    '   if the error bit is set or not.
    ' Read the serial poll status byte. If the
    ' error bit EERR is set in ibsta, display an error
    ' message and exit.
    Call ibrsp(LocalUd, SPollByte)
    If (ibsta And EERR0 Then
    MsgBox ("ibrs) Error!")
    RearmMask = 0
    Exit Sub
    End If
    ' If the returned status byte is &H50 then the instrument
    ' has valid data to send
    If(SPollByte .diamond. &H50) Then
    MsgBox("Serial poll byte is NOT &H50.")
    RearmMask = 0
    Exit Sub
    End If
    ' Read the data. If the error bit EERR is
    ' set in ibsta, display an error message
    ' and exit.
    rdbuf$ = Space$(20)
    Call ibrd(LocalUd, rdbuf$)
    If (ibsta And EERR) Then
    MsgBox ("ibrd Error!")
    RearmMask = 0
    Exit Sub
    End If
    ' Display the Reading.
    MsgBox (rdbuf$)
    ' Rearm Mask is set to zero to disable the
    ' Callback mechanism. This example is only
    ' designed to run once to show flow for using
    ' GpibNotify Control.
    RearmMask = 0
    End Sub
    __________________________________________________________________________

• Inventors
  Hall, Mike; Bean, Clay;
• Assignee
  National Instruments Corporation (Austin, TX)
• Published
  Oct-26-1999
• Current US Classes:
  710/100
  712/228
  718/108
• Application #
  898050
• International Classes
  G06F 019/00; G05B 023/02
• Field of Search
  712/228 709/108 710/100 710/260 710/262 702/123 364/191
• Examiner
  Ray; Gopal C.
• Agent
  Conley, Rose & Tayon, Hood; Jeffrey C.
• US Patent References:
  5717614
  5724272
  5771388
  5845140
  5847955