Using Service Requests in your GPIB application - Developer Zone - N...

http://zone.ni.com/devzone/cda/tut/p/id/4629

Improve your ni.com experience. Login or Create a user profile.

Document Type: Tutorial NI Supported: Yes Publish Date: Sep 6, 2006

Using Service Requests in your GPIB application

Overview For synchronization purposes, if is often necessary for an instrument to communicate that it has finished processing a command and is ready to execute another command set. Suppose a programmer sends a command to an oscilloscope to auto-scale its y-axis. If the eventual goal is to take an amplitude reading, this reading should not occur until the auto-scaling process has completed. How would you be notified when the operation was complete? The most common method for notification that an instrument needs attention for some reason is the assertion of the service request line. Before the implementation of the IEEE 488.2 specification, instrument manufacturers determined the circumstances necessary to generate a service request. This means that a service request might or might not be generated when a 488.1 instrument was finished processing a command. However, the expansion of the status reporting model specified by IEEE 488.2 added significant flexibility and consistency regarding the generation of service requests, thus enabling programmers to create much more powerful GPIB applications.

Table of Contents 1. 2. 3. 4. 5. 6. 488.2 Model Explanation Event Status Register and Event Status Enable Register Service Request Generation Understanding the difference between *OPC and *OPC? Examples Conclusion

488.2 Model Explanation The IEEE 488.1 specification allocated a single status byte register, and only defined bit 6 (Hex 40) in its definition. This bit (RQS) was reserved for service requests. The remaining 7 bits were vendor defined and were used for a variety of messages. The status model expansion defined by IEEE 488.2 allocated three additional instrument registers to provide added flexibility in the generation of service requests. IEEE 488.2 not only added three additional registers, but also defined two more of the bits in the original status byte register. Bit 4, the Message Available (MAV) bit is set high when a message is available in the output queue of the instrument. Bit 5, the Event Status Bit (ESB) can be set high by any enabled event in the Event Status Register. These two additional bits, and the five remaining bits can be used along with the Service Request Enable Register to generate a service request. The IEEE 488.2 status reporting model (Figure 1) is the key to understanding how service requests are generated. The model illustrates the four separate registers present on IEEE 488.2 compliant instruments.

1 of 4

4/19/2012 12:16 PM

Using Service Requests in your GPIB application - Developer Zone - N...

http://zone.ni.com/devzone/cda/tut/p/id/4629

Figure 1. IEEE 488.2 Status Reporting Model Event Status Register and Event Status Enable Register Instruments use the Standard Event Status Register (ESR) to indicate when certain events occur. For example, 488.2 compliant instruments will set bit 7 (PON) high when an off-to-on transition has occurred in the devices power supply. Bit 5 (CME) is reserved for command errors such as syntax errors detected by the instruments parser. Bit 0 (OPC) is reserved for Operation Complete and is frequently used for synchronization purposes. This event bit is set high in response to the *OPC command and indicates that the device has completed all pending operations. The bits of the Event Status Register are very useful when used in conjunction with the Event Status Enable Register (ESE). Figure 1 illustrates the relationship between the ESR and ESE registers. A logical AND between corresponding bits of the two registers will eventually lead to bit 5 (ESB) of the Status Byte Register being set. The ESB bit being set high can lead to the generation of a service request. The bits of the ESE register are set high or low by the instrument programmer. If the programmer needed the Event Status Bit (ESB) set high when either bit 0 or 5 was set in the ESR register, the appropriate bits in the ESE register would have to be set high. This is easily accomplished by writing *ESE 0x21 to the instrument before any other commands. This command sets bits 0 and 5 in the ESE register high. Therefore, when either bit 0 or 5 is set high in the ESR register, the model logic takes over, and the ESB bit is set in the Status Byte Register. It is important to understand that the programmer has full control over the Event Status Enable Register, and the device has control over the Event Status Register. Service Request Generation A quick look at Figure 1 shows that a service request is generated anytime bit 6 (RQS) of the Status Byte Register is set high. Two methods exist for setting this bit. The first method is a carry-over from IEEE 488.1. Some commands might automatically generate a service request when the instrument is finished processing a particular command. This is completely device specific and should be documented in the user manual of every instrument. The second method of setting the RQS bit high is to use a combination of Status bits and their corresponding SRE bits. Once the correct bits are set in the SRE register, the 488.2 Status Reporting Model logic takes over. For example, if the instrument programmer would like a service request generated when a message is available in the output queue of the instrument, bit 4 in the SRE register would have to be set high. Bit 4 would be set high in the SRE register by sending the command "*SRE 0x10". Bit 4 in the Status Byte register (MAV) would be set high when a message is available in the output queue, and since the programmer set bit 4 in the SRE register, a service request would be generated. The MAV bit is always set in the Status Byte register when a message is available in the output queue of the device. However, the RQS bit is set (which generates the service request) only if the corresponding bits are set in the Service Request Enable register. Understanding the difference between *OPC and *OPC? As stated earlier, sending the *OPC command to a device will set bit 0 of the ESR register. The bit will only be set high when all pending operations have finished execution. Therefore, the *OPC command should be sent as the last command before programmatically waiting for a service request. If the ESE register is set correctly (*ESE 0x01), the status model logic will then cause the ESB bit of the Status Byte Register to be set. Then, if bit 5 of the SRE register is set (*SRE 0x20), the status model logic will set the RQS bit, thus generating a service request. An alternative method of generating a service request is to use the *OPC? Query. This query does not affect the state of bit 0 (OPC) in the ESR register at anytime. When this query is performed, all pending operations will complete, and then a "1" is placed in the output queue of the device. Therefore, the MAV bit of the Status Byte register will be set high. If the corresponding bit in the SRE register is set (*SRE 0x10), status model logic will once again prevail and cause a service request to be generated. Examples The following LabVIEW code examples pertain to the National Instruments Instrument Simulator (Rev B.1). The general idea of the examples is to tell the simulator to generate data, and then generate a service request when the data generation command is finished executing. The examples differ in the way that the service request is generated. Example 1 Example 1 illustrates setting the Operation Complete bit of the Event Status Register once all pending operations have completed. A VISA session is first opened to the Instrument Simulator, and then VISA is setup to recognize the SRQ event. The VISA Write function first sets bit 0 in the Event Status Enable (ESE) register, and then sets bits 4 and 5 in the Service Request Enable (SRE) register. By enabling these bits, we are enabling the instrument to assert the SRQ line when either the ESB or MAV bits are set in the Status Byte Register. After setting the register bits, the command to generate sine data is sent. Then, *OPC tells the simulator to set the Operation Complete bit in the Event Status Register. Remember, the instrument will not set the Operation Complete bit until the sine data is completely generated. The program is then told to wait until a service request is generated. Once the service request is recognized, the command to read the data is sent to the simulator, and the data is read back into the read buffer. The VISA event is then disabled, and the ESE and SRE registers are set back to their original states.

2 of 4

4/19/2012 12:16 PM

Using Service Requests in your GPIB application - Developer Zone - N...

http://zone.ni.com/devzone/cda/tut/p/id/4629

When this program is executed, the Status Byte returned is hex 60. This is the expected value because of the way the service request was generated. If interpreted, hex 60 means that bits 5 and 6 are set in the Status Byte. Bit 6 means that the RQS bit was set (a service request was generated), and bit 5 means that the ESB bit was set. The ESB bit was set because we enabled bit 0 in the Event Status Enable (ESE) register, and the OPC bit was set in the ESR register (due to *OPC). If we had never enabled bit 0 in the ESE register, a service request would not have been generated because the model logic would have never set the ESB bit of the Status Byte Register. Likewise, if we had not enabled bit 5 in the SRE register, no service request would have been generated as a result of the ESB bit being set high. Example 2 Example 2 generates a service request with the use of the *OPC? command. Remember that *OPC? does not ever affect the state of the OPC bit in the Event Status Register. *OPC? will generate a "1" in the output queue of the instrument whenever all pending operations have completed. Therefore, the service request should be generated based on the MAV bit being set high. Notice the additional VISA read in the code after the program is finished waiting for a service request. This additional read is included to read the "1" placed in the output queue as a result of the *OPC? command.

When this code executes, a Status Byte of hex 50 is returned. If interpreted, hex 50 means that bits 4 and 6 of the Status Byte register are set high. Again, bit 6 means that the RQS bit was set, thus generating the service request. Bit 4 means that the MAV bit was set high. This is expected because of the behavior of the *OPC? command explained previously. Example 3 When example 3 is executed, the Status Byte returned is hex 70. This means that bits 4, 5, and 6 of the Status Byte Register are set. Bit 6 (RQS) makes sense because we generated a service request. Bit 5 (ESB) makes sense because we enabled bit 0 in the ESE register, and we also sent the *OPC command. The IDN? command sent to the simulator will simply tell the instrument to identify itself. The instrument will place its identification string in the output queue of the instrument. This is the reason that bit 4 is set. So what actually caused the service request to be generated? The key is the bits set in the Service Request Enable register. Notice that the command sent in the first write buffer enables only bit 4 (*SRE 0x10) in the Service Request Enable register. Therefore, according to model logic, only bit 4 (MAV) being set in the Status Byte register would generate the service request. This means that the data in the output queue of the instrument is causing the service request to be generated.

3 of 4

4/19/2012 12:16 PM

Using Service Requests in your GPIB application - Developer Zone - N...

http://zone.ni.com/devzone/cda/tut/p/id/4629

Conclusion The generation of service requests allows programmers to effectively synchronize GPIB command sequences. The expansion of the status reporting model dictated by IEEE 488.2 has added significant flexibility to GPIB programmers. The expanded status reporting model has also made the programmatic generation of service requests consistent across all IEEE 488.2 compliant instruments. A fundamental understanding of the status reporting model is necessary to take advantage of this added flexibility and consistency.

Legal This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).

4 of 4

4/19/2012 12:16 PM