Using Instrument Status Registers and Service Requests in LabVIEW

Most message-based instrument communication is just a series of simple synchronous writes or queries to your instrument. However, by understanding instrument status registers and using service requests and polling techniques, you can improve the robustness of your instrument control applications.

This application note describes situations and solutions that use instrument status registers with service request or polling techniques to handle situations where simple VISA write and read operations are not sufficient for robust instrument control.

This application note uses the VISA application programming interface (API) in LabVIEW to show the application-side control mechanism for asynchronous communication. Furthermore, it assumes you are familiar with using the VISA Read and VISA Write operations as well as the VISA property node to set or get commonly used properties, such as Timeout. While this application note uses VISA, many of the concepts also apply to instrument control applications that use other APIs, such as the traditional NI-488 and VXI interfaces. Additional references noted at the end of this document use these other APIs.

This application note focuses on IEEE 488.2-compliant instruments that are compatible with service requests and serial polls, which includes the majority of instruments that use one of the following VISA resource classes: GPIB INSTR, USB INSTR, or TCPIP INSTR. While many of the concepts described in this document apply to other buses, the exact behavior of VISA and the instrument might differ.

This application note describes the instrument status registers, which are used to set up the instrument for asynchronous communication. Because many instrument status registers are unique to a given instrument, this application note focuses on the core registers used in IEEE 488.2-compliant instruments and briefly describes other types of instrument status registers.

Examples

This application note references several accompanying examples. All of these examples are in the Status Registers and Service Requests.llb. The examples that include "learn" in the name are designed for interactive instruction. The block diagrams of these "learn" examples typically use low-level VISA commands. The examples that include "program" in the name are designed to learn from the programmatic implementation. The block diagrams of these "program" examples often include utility VIs that you can reuse in your applications. These utility VIs are also in Status Registers and Service Requests.llb. View VI Tree.vi to see all the examples and utility VIs.

Need for Advanced Instrument Control Techniques

For most message-based instrument communication, synchronous writes and queries are sufficient for robust instrument control. The diagram in Figure 1 shows how the VISA API can perform a DMM voltage configuration and measurement.

Figure 1.

In this simple example, the instrument is instructed to take a single measurement. The instrument can respond immediately to the commands and process each command quickly so there is no apparent delay in reading the measurement response.

While this simple write-read model is sufficient for most instrument control use cases, you can quickly run into situations where you need more control over the timing of instrument operations. Consider a situation where you want to control a DMM to take a multipoint measurement of 500 readings. Such an operation may require several minutes for the instrument to obtain the data. Instead of performing the read operation immediately after the write operation, a better solution is to ensure that data is available before reading. With IEEE 488.2-compliant instruments, there are commonly used techniques to ensure that the data is available before reading. Before we investigate solutions, we will first identify and categorize the types of situations where more sophisticated communication is needed.

Categories of Instrument Control Situations

Although thousands of instruments perform a variety of different measurement and stimulus operations, there is commonality in the types of instrument control operations you perform. Therefore, it is convenient to categorize the situations so that you can identify the solutions that address your particular need. For example, the multipoint measurement scenario described previously is an example of query synchronization. This application note defines the following categories of instrument control operations:

Query Synchronization

Query synchronization is when you want to ensure that the instrument response is ready to be read before retrieving the data from the instrument output buffer. Query synchronization involves first sending a query command to your instrument. For example, you might send the command FETCH? to retrieve data. You then want to be notified that the data is available in the instrument output buffer before attempting to read the data from the instrument. Typically, query synchronization is used when the response from the instrument is not immediate. Below is a list of common situations where you might need query synchronization:

• Wait for data from a multipoint measurement to complete
• Wait for a waveform acquisition to complete
• Wait for response to a self-test or calibration

Although you can use query synchronization in situations where the instrument response is immediate and deterministic, it often adds complexity to your instrument control application. For example, because instruments typically can respond immediately to an identification query, *IDN?, you would not need to implement special query synchronization techniques. In this case, a simple write-read operation would minimize code while ensuring sufficient robustness.

Command Synchronization

Command synchronization ensures the completion of one instrument operation before the start of a second operation. Typically, command synchronization is used when the result of the second operation depends on the completion of the first operation. For example, to instruct an oscilloscope to perform an autosetup routine followed by a query for the waveform data, ensure that the autosetup routine is completed before retrieving the waveform data.

Below are common situations where you might need command synchronization:

• Wait for an autosetup routine on an oscilloscope to complete before attempting other configuration or waveform acquisition
• Wait for a triggered acquisition to complete before taking measurements on the acquired waveform

Some instruments process commands synchronously as they are received. In these cases, no special command synchronization is necessary because the instrument itself ensures synchronization. However, to more efficiently process commands, many high-performance instruments can process commands in parallel. If your commands are not dependent on each other, no special command synchronization is necessary. For example, setting oscilloscope horizontal settings can generally be performed in parallel with setting the vertical settings.

Instrument Error Handling

Instrument error handling notifies you of an instrument error. You can successfully send and receive data from the instrument without realizing that an instrument error occurred. For example, a command error is an error that occurs while the instrument is parsing a command or query.

Watching and Responding to Events

Watching and responding to events is the catch-all for handling various instrument events whose condition is set in one of the event registers. All IEEE 488.2-compliant instruments can watch for and respond to standard events such as instrument error conditions. However, many instruments also have instrument-specific status registers with which you can respond to measurement-specific events. For example, when using a DMM, you might want to be notified when a voltage overload condition occurs. On an oscilloscope, you might want to be notified when a trigger event occurs.

Note: Command and query synchronization are special examples of watching and responding to events. With command synchronization, you respond to the operation complete event. With query synchronization, you respond to the message available event. With instrument error handling, you respond to error events in the Standard Event Status Register. Similarly, depending on the situation, you can choose one of multiple approaches to respond to the event.

Programmatic Approaches to Accessing Instrument Status

Just as we categorized the instrument control situations, it is convenient to categorize the different types of programmatic approaches you can use to handle the various situations. This application note defines the following programmatic approaches to handling the instrument control situations defined earlier:

• Long Timeout
• Serial Poll
• Service Request
• Query Status

The general concept of each technique described below. The specifics of using each approach in LabVIEW are described later in the Programmatic Approaches section.

Long Timeout

When waiting for the instrument to respond with data, you can often get away with just setting a long timeout for your read operation. This approach is simple to conceptualize and implement. However, it is only applicable for query synchronization, where you are waiting for data to become available. It is not applicable for command synchronization or checking for instrument events, such as error conditions.

Serial Poll

Serial poll is a special bus operation where the instrument controller obtains the status byte register value. This is accomplished without sending a message command to the instrument. Besides being more efficient than an instrument query, you can also use a serial poll while an instrument query is pending.

Note: A serial poll returns only the contents of the status byte register. However, because the status byte register is a summary of other registers, you can use enable registers to monitor other desired instrument events.

A serial poll is not compatible with all bus interfaces. However, the VISA Read STB could still be a valid operation with some serial instruments. If the VISA IO Protocol property is set to Serial-TCPIP/488, the query *STB?\n is sent to the instrument to retrieve the status byte.

Service Request

A service request is a mechanism that enables an instrument to asynchronously notify the host computer or controller. Use enable registers to determine which instrument events assert a service request.

Query Status

The query status approach is nothing more than sending query commands to the instrument to read the instrument status registers.

Note: You should query the status of an instrument only when no other queries are pending. Sending a status query to an instrument before reading the response to an existing query results in a query error. To check the status of an instrument after sending an instrument query, you should use the serial poll or service request event handling.

Understanding the Status Registers

Many message-based instruments implement a status reporting structure based on the IEEE 488.2 standard. Figure 2 shows a model of the core reporting structure. The core status registers consist of a Status Byte Register, a Standard Event Status Register, and two enable registers.

Each bit in the standard event status register (SESR) represents a type of event that may occur in the course of using the instrument, such an error condition. When the event happens, the instrument sets the bit associated with the event to true. The status byte register represents a summary of the standard event status register, the output buffer, and other instrument-specific registers. The status byte register asserts a service request.

The standard event status register and the status byte register each have an associated enable register. The standard event status enable register (SESER) defines which bits in the associated register are used generate a summary flag to set the "standard event" bit in the status byte register. This is accomplished by first performing a bit-wise AND of the event register and the associated enable register. The resulting bits are ORed together to generate a resulting summary bit.

The service request enable register (SRER) defines which bits in the status byte register set the "service request" bit. When the "service request" bit is set to True, the instrument asserts a service request.

You typically use enable registers when you want to use service requests or you want to monitor multiple event registers. By reading only the status byte register, you can obtain a summary status of other registers. Each core register is described in more detail below.

Core Registers

Status Byte Register

The status byte register is the main status reporting register on any IEEE 488.2-compliant instrument. The status byte register represents a summary of the standard event status register, the output buffer, and other instrument-specific registers. The status byte register asserts a service request.

You can be notified of the occurrence of an event in the status byte register by either querying the status byte register or by a service request. You can perform the query explicitly using a command query or through a serial poll operation. To query explicitly, you send the *STB? query command to the instrument. To query using a serial poll, you call the VISA Read Status Byte function. The response to the query is a decimal value that corresponds to the binary-weighted sum of all the bits in the register.

Performing a query clears the bits in the register, with one notable exception. When you query, the "request service" bit is not cleared. Send *CLS to clear the entire register. Sending *RST does not clear the register.

The Status Byte Register is also referred to as the Service Request Event Register.

Standard Event Status Register

The standard event status register records eight different events that might occur on your instrument. These events include Power-On, User Request, Command Error, Execution Error, Device Dependent Error, Query Error, Request Control, and Operation Completed. You may query the Standard Event Status Register directly by using the *ESE? command. The response to the query is a decimal value that corresponds to the binary-weighted sum of all the bits in the register. Querying the register clears all the bits in the register.

Service Request Enable Register

The service request enable register controls which bits in the status byte register cause a service request. The bits in the enable register are logically ORed with the corresponding bits in the status byte register to determine which events cause a service request. The Service Request Enable Register can be both set and queried. To set the bits in the Service Request Enable Register, send the *SRE <value> command where <value> is the decimal value which corresponds to the binary-weighted sum of the bits you want to enable. Querying the Service Request Enable Register does not clear the bits.

Standard Event Status Enable Register

By setting the bits in the Service Request Enable Register that correspond to events in the Standard Event Status Register, you can configure an instrument to set the "Standard Event" in the Status Byte Register when one of the events in the standard event status register occurs. Setting this "Standard Event" bit is therefore a summary of the events in the Standard Event Status Register. You can assert a service request when one of the standard events occurs. To set the bits in the Standard Event Status Enable Register, send the *ESE <value> command where <value> is the decimal value that corresponds to the binary-weighted sum of the bits you want to enable. Querying the Standard Event Status Enable Register does not clear the bits.

In addition to the core IEEE 488.2 registers, instruments often make use of other status registers. These additional status registers are 16-bit registers that report events specific to a particular instrument. Below is an introduction to these instrument-specific registers. Refer to your instrument programming manual for specific details of the instrument-specific registers your instrument defines.

Event Registers

Like the Standard Event Status Register, instrument-specific event registers report status of events that may occur during the course of use of the instrument. These event registers are read-only, latched registers. Therefore, once set, the bits remain set until cleared by a query of the event register or a *CLS command is sent to the instrument. Subsequent event changes are ignored.

An example of an instrument-specific event register is the Questionable Data Register in the Agilent 34401A multimeter. This register defines such events as Voltage Overload and Ohms Overload.

Enable Registers

Like the Standard Event Status Enable Register, instrument-specific enable registers define which bits in the corresponding event register are logically ORed together to form a single summary bit. The summary bit then becomes an event bit in another register. For example, the summary bit from the Questionable Data Enable Register on the Agilent 34401A sets bit 3 of the Status Byte Register. Enable registers are not cleared when queried.

Additional Registers

Typically, if an instrument has additional registers, they define event and enable registers. However, some instruments also have associated condition and transition registers. When defined, these condition and transition registers are associated with event and enable registers. Like an event register, each bit in a condition register represents the current state of an event. However, the bits in a condition register are not latched. Therefore, if the event changes, the associated bit in the condition register also changes. Typically, if an instrument has a condition register, the events from the condition register set the events in an associated event register. The transition register determines the state transitions that set the corresponding bits in the event register. These transition registers can configured so that either a transition of a condition bit from a 0 to 1 or a 1 to 0 latches the associated bit in an event register.

The following programmatic approaches were introduced earlier in the Programmatic Approaches for Accessing Instrument Status section:

• Long Timeout
• Serial Poll
• Service Request
• Query Status

The implementation details of each approach are in the following sections. Along with general procedural details, each section includes references to examples.

Long Timeout

Figure 3 shows a block diagram of a simple read and write operation that incorporates the VISA Timeout property node to wait for data to be available.

Figure 3.

The example performs the following operations:

1. The VISA Write operation sets up a digital multimeter to take 25 data measurements (:SAMP:COUN 25;), initiates the measurements (:INIT;), and requests the data (:FETCH?) .
2. The VISA Property node reads the current timeout value so that it can be reset to the same value later and then sets the timeout value temporarily to 60000 ms.
3. The VISA Read retrieves the data.
4. The VISA Property node sets the timeout value back to the original timeout value.
5. Simple Error Handler.vi notifies the user if any VISA operation fails.

A temporary timeout of 60 seconds might be needed because the time needed for the instrument to acquire 25 data points is longer than the time necessary for other instrument control operations to complete in the rest of the application. Set the timeout of an operation to slightly longer than the longest expected wait for an instrument response.

As mentioned earlier, the use of a long timeout is simple to conceptualize and implement. However, if you are using GPIB to control multiple instruments concurrently, all other bus activity must wait until the read completes. Therefore, if you are controlling multiple instruments simultaneously, use polling or service requests.

Refer to Read with Temporary Timeout – simple.vi for an example of how to incorporate the VISA Timeout property node in your application.

Polling

For IEEE 488.2-compliant instruments, you typically poll an instrument by calling the VISA Read Status Byte function within a loop until the returned status byte indicates the desired event occurred. Polling the status byte, you can obtain summary information about all the instrument events.

Using Polling for Query Synchronization

Figure 4 shows an example of a poll to wait until the instrument completes 25 data measurements before retrieving the data.

Figure 4.

The example performs the following operations:

1. The VISA Write operation sets up a digital multimeter to take 25 data measurements (:SAMP:COUN 25;), initiates the measurements (:INIT;), and requests the data (:FETCH?) .
2. The status byte is continuously polled until the fourth bit is set to true. Bit 4 corresponds to the Message Available (MAV) bit.
3. The VISA Read retrieves the data.

The Message Available bit in the status byte register is set when data is available in the output buffer.

Note: As with other polling techniques in LabVIEW, it is important to include a wait function in the poll loops so to free up your application and operating system to handle other tasks more effectively.

Note: It is important to understand usage details of the message available bit for your particular instrument. When the above example is used with the Agilent 34401A multimeter, the message available bit is set only after all the 25 measurements are completed and transferred to the output buffer. The behavior of the message available bit differs when using the READ? query. The READ command instructs the instrument to transfer the measurement data to the output buffer after each measurement. Therefore, the message available bit is set to true after the first measurement data is completed.

Refer to Query Sync with Serial Poll - simple.vi for a simple example of how to perform a query synchronization using serial poll.

Using Polling for Command Synchronization

Refer to Cmd Sync with OPC and Serial Poll - learn.vi for an interactive example of using serial polls for command synchronization.

Refer to Cmd Sync with OPC and Serial Poll - program.vi for an example of how you would programmatically implement a serial poll for command synchronization.

Service Request

A service request is a hardware mechanism an instrument uses to notify the host computer that certain events or conditions occurred on the instrument. To handle service requests using VISA, you need to learn about how VISA handles events.

VISA Event Functions

VISA defines a common mechanism for notification when certain events occur. Service requests are one of the most common types of events. However, VISA also allows for notification of other events, such as interrupts on register-based instruments.

In LabVIEW, VISA uses a queuing mechanism where all occurrences of a specified event are maintained in an event queue. Because VISA supports many different types of events, it is important to specify which events you want VISA to monitor. For the purposes of this application note, we want VISA to maintain a queue of service requests. Therefore, you must explicitly set the event type to "Service Request."

To manage the event queue, VISA has four low-level VISA events functions and one service request-specific operation. You can find these event functions in the VISA»VISA Advanced»Event Handling palette.

The VISA Enable Event function informs VISA of the event types it should monitor and place in the event queue. Note that a queue is maintained for each VISA session and each event type.

The VISA Wait on Event function is a synchronous operation that waits the specified amount of time for the specified event to occur. If an event occurs, the event is removed from the VISA queue. The VISA event queue acts as a FIFO (first in first out) buffer. Therefore, if multiple events are in the event buffer, the VISA Wait on Event operation retrieves the oldest event first.

VISA Wait for RQS.vi is a VI specifically designed to wait on service requests. If you look at the block diagram, you will notice that this VI uses the VISA Wait on Event function followed by the VISA Read Status Byte function. You need to read the status byte to verify the nature of the service request. Suppose you enable service requests to occur when either an error condition occurs or when data is available in the output buffer. By reading the status byte after the service request, you can determine which of the two events causes the service request.

The VISA Disable Events function stops events from being added to the event queue. Note that this function does not empty the event queue.

The VISA Discard Events function empties the entire queue. It is a good idea to discard events after you have enabled events to ensure that you are starting with an empty event queue. If the event queue is not empty, you might process a stale event with the VISA Wait on Event function. Basically, instead of waiting for a new event, the operation returns immediately because an event is already in the queue.

General VISA Event Handling Procedure

Below is the basic procedure for handling service requests using VISA. Refer to the examples section for specific examples that use this procedure.

1. Set up your instrument to assert a service request for a desired event. This includes the following:
   1. Clear the status byte registers of the instrument by sending the *CLS command. Clearing the status byte registers ensures you are not processing stale events. Note: Calling the VISA Clear function does not clear the registers. Use the VISA Clear function to clear the output buffer.
   2. Set the status byte registers to assert a service request for the specified events. At a minimum, this requires you to set the status byte enable register mask using the *SRE command. For example, if you want to assert a service request when data is available in the output buffer, you set the "Message Available" mask bit (bit 4) by sending *SRE 16 to the instrument. To fully specify the requested event, you may need to send additional commands to set other enable registers, such as the Standard Event Enable Register.
   3. Depending on the type of event you are monitoring, you may need to send the commands to the instrument to initiate the operation, which results in a service request. For example, to be notified when data is available, send a query command to the instrument. So, to initiate and retrieve measurement data from a multimeter, you might send :INIT;:FETCH?
2. Enable VISA to monitor service requests by calling the VISA Enable Event function.
3. Wait on the event to occur using the VISA Wait on Event function or Wait for RQS.vi. If you are expecting the event, you typically set the timeout to a value slightly longer than the expected completion time. However, if you are monitoring an event which may or may not occur, such as an instrument error, you might be calling VISA Wait on Event function in a while loop with a zero timeout, which essentially allows your application to check if a service request is in the event queue.
4. Halt event handling. Unless you are interested in subsequent events, it is best to halt events from being added to the event queue. Use the VISA Disable Event function to stop events from being added to the queue. Depending on your application, you may also want to set the instrument status registers so that the instrument no longer asserts service requests. Sending *SRE 0 to the instrument clears all the mask bits so that there are no events that result in a service request.
5. Act on the received events. If you enabled the instrument to assert a service request when data is available in the output buffer, you can now perform a VISA Read operation to retrieve the data. If, on the other hand, the instrument was set up to assert a service request when an error occurred, you want to handle the error condition.

Using Service Requests for Query Synchronization

Figure 5 shows how to use VISA event handling to implement query synchronization to wait until the Agilent 34401A DMM has taken 15 measurements and placed them in the instrument output buffer.

Figure 5.

This example follows these steps:

1. Clear the IEEE 488.2 event registers and set status byte enable register so that only the "Message Available" bit is true. This masks out all other events so that a service request is asserted only when data is available in the output buffer. You can clear the registers and set the mask with one VISA Write operation by sending two concatenated commands -- *CLS;*SRE 16;.
2. Discard service request events in the VISA event queue. This step ensures that there are no preexisting events in the queue that would result in a premature return in Wait for RQS.vi.
3. Enable VISA to monitor service requests by calling the VISA Enable Event function and set event type to "Service Request."
4. Send the query command to the instrument. In this example, we are also configuring and initiating the measurement. Depending on your application, the configuration might be performed earlier in your application. The key command that must be sent here is the command that results in data being placed in the instrument output buffer. In the case of the Agilent 34401A multimeter, the :FETCH? command places data in the output buffer.
5. Wait on the event to occur using Wait for RQS.vi. In this example, we are taking 15 samples that should be completed within the specified 25 seconds.
6. Stop service request events from being added to the event queue by calling the VISA Disable Event function.
7. Read the data from the instrument output buffer.

Refer to Wait on Data Availability with SRQ - learn.vi for an interactive example of using service requests for query synchronization.

Refer to Wait on Data Availability with SRQ - program.vi for an example of how you would use service requests programmatically for query synchronization.

Using Service Requests for Command Synchronization

Before we look at programmatically handling command synchronization, we must first understand how to use the IEEE 488.2 registers to know when an operation is complete. Bit 0 of the Standard Event Status Register is reserved for the Operation Complete (OPC) event. The Operation Complete event occurs when the instrument receives the *OPC command and all previous commands are complete. So, to ensure that the instrument completes an operation, you can append *OPC to the command.

Note: Command synchronization using *OPC is not available for all commands. Refer to your instrument manual on restrictions. For example, the Agilent 33120A User Guide indicates that *OPC is "used only in the triggered burst mode and triggered sweep mode." Some instruments immediately set the Operation Complete bit to True, even if the operation is still executing.

This example follows these steps:

1. Clear the IEEE 488.2 event registers and both the enable registers to assert a service request when operation complete. Mask bits need to be set in both the Standard Event Enable Register and the Status Byte Enable Register. By setting the Standard Event Enable Register mask to 1 (*ESE 1), we are enabling the mask that corresponds to the Operation Complete event. By setting the Status Byte Enable Register mask to 32 (*SRE 32), we are enabling the mask that corresponds to the Standard Event summary bit. This Standard Event summary bit is set to true if any of the nonmasked events in the Standard Event Status Register occur.
2. Discard service request events in the VISA event queue. This step ensures that there are no pre-existing events in the queue that would result in a premature return in Wait for RQS.vi.
3. Enable VISA to monitor service requests by calling the VISA Enable Event function and set event type to "Service Request."
4. Append *OPC to the AUTOS EXEC command and send to the instrument to initiate the auto setup routine.
5. Wait on the event to occur using Wait for RQS.vi.
6. Stop service request events from being added to the event queue by calling the VISA Disable Event function.
7. Send the next command to the instrument. In this example, we instruct the oscilloscope to stop acquisition.

Refer to Cmd Sync with OPC and SRQ - learn.vi for an interactive example of using service requests for command synchronization.

Refer to Cmd Sync with OPC and SRQ - program.vi for an example of how you would programmatically use a service request for command synchronization.

Using Service Requests to Respond to Events that May Not Occur

Let's look at the situation where an instrument-specific event may or may not occur. For this example, we will look at responding to a measurement overload condition using the Agilent 34401A multimeter. There are easier ways to handle an overload condition, but checking for overload condition with service requests helps illustrate how you might handle instrument events that may or may not occur. Refer to the Query Status of Instrument-Specific Events section for more information about handling an overload condition with LabVIEW.

Consider an application that repeatedly takes measurements within a While loop. If performance is a concern, you might want to minimize instrument control within the loop. Therefore, you can set up a parallel loop that uses VISA events to monitor service requests. For each loop iteration, the VISA Wait on Event function checks if a service request exists in the VISA queue. Because the VISA Wait on Event is only checking the queue, the specified timeout value can be zero. If no service request exists in the VISA event queue, the resulting timeout error should be ignored so that future checks occur.

Refer to AG34401A Check Overload Using SRQ – learn.vi for an example of how you might want to respond to events that may not occur. It is best to use another technique when the timing of the possible event is known. This example also shows how the techniques shown in this application note can be used with instrument drivers. This example requires that you install the Agilent 34401A LabVIEW Plug & Play instrument driver.

Query Status

Each status register typically has an associated command and query to set or retrieve the contents of the register. Therefore, to check the status of the register, you send the appropriate register query command. For example, to read the contents of the Standard Event Status Register, you send a "*ESR?" query command to the instrument. The instrument returns a weighted sum of the register bits. For example, a response message of 12 to the *ESR? query indicates that both a query error and a device error occurred.

The status byte register is a special case and can be queried by either sending the *STB? query or by calling the VISA Read Status Byte function.

Query Status of Instrument-Specific Events

It is often possible to know when an instrument-specific event might occur. For example, if you are taking a multimeter measurement, an overload condition occurs only after an instrument takes a measurement. Because the application program controls when the instrument takes a measurement, you can easily determine an overload condition without using special event handling. Figure 7 shows how you can check for an overload condition without relying on instrument notification.

Figure 7.

In this example, you use LabVIEW to check the measurement value for an overload condition after parsing the measurement. This approach minimizes the instrument control communication because there are no additional queries performed to the instrument. By performing the check in LabVIEW, you also improve application performance. The block diagram code in Figure 7 shows how simple this can be.

However, if you want to rely on the instrument for status, you can use the following approaches:

1. Directly query the instrument-specific register after each measurement. In the case of the Agilent 34401A multimeter, the STAT:QUES:EVEN? query can determine whether a measurement overload condition occurred. While this approach is sufficiently robust, performing an extra instrument query impacts performance if you are performing many read operations.
2. Set up the status byte register so that it provides a summary of the instrument-specific events. By setting the status byte register, you can use the check status method in combination with other event handling techniques. In the example shown in Figure 8, the status byte register is configured so that only one event, the "Ohms Overload" condition, results in the Request for Service bit to be set to true in the Status Byte Register. Therefore, with a simple serial poll, you can determine an overload condition.

Figure 8.

If the status byte register in the example shown in Figure 6 was configured so that multiple events would cause bit 8 to be set, you may need to perform an additional query to the instrument to discern the exact nature of the error. Similarly, if you were using service requests and the status byte register was configured so that multiple events cause the Request for Service bit to be set, once you determine the instrument is requesting service, you may need to query both the status byte register and any associated event registers for more detailed information. While checking status might perform additional instrument queries, the performance impact is minimized as the extra query occurs only if the instrument indicates it requests service.

Several examples in the Status Registers and Service Requests.zip check for status in combination with other event handling to respond to possible instrument errors. The following examples check for instrument errors using the standard event status register:

Cmd Sync with OPC and SRQ - learn.vi.

Cmd Sync with OPC and SRQ - program.vi.

Wait on Data Availability with SRQ - learn.vi.

Wait on Data Availability with SRQ - program.vi.

Cmd Sync with OPC and Serial Poll - learn.vi.

Cmd Sync with OPC and Serial Poll - program.vi.