6. Measurement Synchronization

Measurement synchronization is one of the most important points to keep in mind when writing any remote-control application. Neglecting this aspect of your program leads to unpredictable behavior, unrepeatable results and a lot of frustration. A clear sign of improper measurement synchronization is, when you have to insert fixed pauses into your application in order to get it running.

Let us first define Measurement Synchronization for the purpose of this chapter:

Today’s measurement instruments are complex devices with their own operating systems. Your measurement application does not have to care about the instrument's status all the time. Measurement synchronization is the method by which you make sure, that at important points of your program (SyncPoints), your instrument is in the state you expect.

An example of measurement synchronization with an oscilloscope and a DUT that generates a non-periodic signal:

From the picture above, you see there are idle sections in your program that have to wait for the instrument to catch up. Notice that these idle times are dynamic in length. They have to adapt to the different conditions (e.g. speed of your PC, different instrument settling and acquisition times). How can you achieve this? The best way is to let the instrument tell you when it is ready. Different synchronization methods are presented after the following notes.

Additional notes:

• Always operate an acquisition instrument (Oscilloscope, Spectrum Analyzer, Powermeter…) in single acquisition mode. Only then, you can be sure your measurement results come from the last completed acquisition, not from the one before or from the not yet completed acquisition. Most importantly: any synchronization method works properly only in the single acquisition mode.
• Basic settings and Trigger settings do not need to be synchronized. The only important key point comes at the end where you want to make sure all the settings have been applied (SyncPoint ‘SettingsApplied’).
• After the trigger has arrived, the oscilloscope starts waveform acquisition. Your program must wait until it has finished (SyncPoint ‘AcquisitionFinished’).
• Reading the waveform after this SyncPoint makes sure the result comes from the most recent acquisition.

Synchronization mechanisms overview

In the following four chapters we present different synchronization mechanisms sorted from the simplest to the most complex one:

• *OPC? query
• Status Byte (STB) polling
• Waiting for Service Request (SRQ)
• Service Request (SRQ) event

*OPC? query synchronization

This is the easiest and the most often used synchronization method.

When you send the query *OPC? to an instrument, it delays the response until all the pending operations have finished. Therefore, the Idle periods in your program are taking place in VISA Read operations where your program waits for the instrument to respond to the *OPC? query. It is not the response itself that matters here, but rather the delay it generates.

Important! Since the *OPC? is a query, you must not forget to read the response from instrument with the VISA Read() function. Otherwise your instrument generates an error 'Query Interrupted' by the next query. This is important not only for the *OPC? query, but for all queries.

Here, we should mention one additional parameter – VISA Timeout. VISA Timeout provides the mechanism by which you can define the maximum time to wait in VISA Read operations before they end with a VISA timeout error. Since this value is individual, and it depends on your current task duration, make sure you set the VISA timeout appropriately – a timeout too small might generate unwanted errors during regular operations, a timeout too big makes your program non-responsive in case a real error occurs.

Advantages:

• Simple and effective in most cases.
• Does not use session's control channel (see the STB polling method), therefore works also with RawSocket and Serial connection.

Disadvantages:

• Blocks the communication with the instrument until it responds. This can be criticial for long-lasting operations, where your application becomes non-responsive.

Status Byte (STB) polling synchronization

This method is used by Rohde & Schwarz instrument drivers. If you use direct SCPI commands, find the examples of implementation at the end of this chapter. Let us first have a look at the flowchart showing the procedure. The explanation follows afterwards.

To explain the flowchart, we need to have a look at instrument Status Subsystem - a hierarchical structure of registers with the main one on the top called Status Byte (STB). It is an 8-bit register defined in the IEEE 488.2 standard. Each of its bits has different meaning and serves as a summary flag for the registers down the status registers hierarchy chain. The complete status subsystem structure you find in any Rohde & Schwarz instrument remote control user manual (search for the term 'Status Byte'). The following picture shows the Status Byte register plus the second register Event Status Register (ESR):

• The first operation of the flowchart sets the ESE Filter to 1 (Bit 0 = 1). That means, we are only interested in the ESR Bit 0 - OPC. You just need to send this command once, after initiating the connection, or after *RST command.
• Next operation queries the ESR register value with the command *ESR?. This register is an EVENT register - you clear its value on reading. This resets the ESR Bit 0 - OPC back to 0.
• Next operation sends the command you want to synchronize. In our case, it is the SCPI command SING that arms the oscilloscope for a single acquisition. *OPC (without the question mark!) at the end of the string tells the instrument: After all commands in this string are executed and finished, set the ESR Bit 0 - OPC to 1. For this reason, you had to reset it to 0 before. Otherwise it might have been set to 1 by some of the previous actions and your STB polling loop would finish incorrectly after its first iteration.
• Next operation is Status Byte polling loop. You query Status Byte until the Bit 5 - Event Status Summary is set to 1. The Status Byte value can be retrieved in two different ways - either with the SCPI command *STB?, or with a special VISA function called ReadSTB(). What is the difference? The *STB? is a standard SCPI command using VISA I/O buffers. The function ReadSTB() communicates over a separate channel called Control Channel, and does not interfere with the standard SCPI write/read communication. It is also optimized for quicker response times. We recommend including a progressive polling delay inside this loop. For example: no delay the first 10x, then 1ms delay the next 100x, 10ms delay the next 1000x and so on... To prevent endless loops, Rohde & Schwarz instrument drivers use timeout called OPC Timeout.
• After the loop has ended, the ESR Bit 0 - OPC is reset again with the SCPI command *ESR?

Advantages:

• Does not block the communication with the instrument. You can in parallel send SCPI commands and receive responses.
• Suitable for long-lasting operations. For example, self-alignments or self-tests.

Disadvantages:

• More complex to implement.
• Does not work with the RawSocket and Serial connection, since they do not support control channel function VISA ReadSTB().

Advanced methods with Service Request (SRQ)

Waiting for Service Request (SRQ) synchronization

This method is similar to the previous Status Byte polling synchronization, but instead of STB Polling loop, it uses a function VISA WaitOnEvent() configured to wait for Service Request event. Examples for this type of synchronization are available at the end of this chapter.

To use the mechanism, you need to:

• Perform one-time setting after reset *ESE 1;*SRE 32 (see above picture Instrument status subsystem registers). This sets ESE Filter to react on the ESR OPC bit just like in the previous synchronization method with STB polling. "*SRE 32" sets the SRE Filter to generate Service request if the Event Status Summary bit of the STB register is set to 1.
• Before sending the command to synchronise enable the service request event with VISA EnableEvent() function.
• Send the command to synchronize with the ;*OPC at the end.
• Call the VISA WaitOnEvent() function. It waits until the Service Request event arrives, or the timeout expires.
• Disable the service request event with VISA DisableEvent() function.

Advantages:

• Compared to the previous method, no STB polling loop implementation is necessary.
• IO Trace is shorter and better readable.

Disadvantages:

• Your application in LabVIEW and MATLAB cannot be interrupted during the VISA WaitOnEvent() execution. This can be a problem in case of commands that take long time to complete, e.g. selftest query *TST?
• Not supported with RawSocket and Serial connection.

Service Request (SRQ) event synchronization

The main idea is, that you initiate an instrument's task and focus on something else. When the instrument has finished the task, VISA invokes a function of your choice. This function is called Event handler.

Examples for this type of synchronization in C# and LabWindows/CVI are available at the end of this chapter.

To use the Service Request event synchronisation mechanism, you need to:

• Perform one-time setting after reset *ESE 1;*SRE 32 (see above picture Instrument status subsystem registers). This sets ESE Filter to react on the ESR OPC bit just like in the previous synchronization method with STB polling. *SRE 32 sets the SRE Filter to generate Service request if the Event Status Summary bit of the STB register is set to 1.
• Before sending the command to synchronise you have to register your callback function with VISA InstallHandler() function and enable the Service Request mechanism with VISA EnableEvent() function.
• Send the command to synchronize with the ;*OPC at the end. After the command execution is finished, VISA calls your registered function.

Advantages:

• You can perform other tasks in the meantime.
• Ideal for multi-threading applications.

Disadvantages:

• More complex to implement.
• Not supported with RawSocket and Serial connection.
• Not supported in LabVIEW and in MATLAB.

Direct SCPI Command Examples

Examples of the above measurement task with the *OPC? query synchronization, plus:

• STB polling synchronization
• Wait for Service Request synchronization
• Service Request event synchronization (in Python, C# and LabWindows/CVI)

Instrument Driver Examples

Examples of the above measurement task:

Other Resources

More information on the topic of measurement synchronization you can find here:

• 1EF62: Hints and Tricks for Remote Control of Spectrum and Network Analyzers
• 1GP79: Top Ten SCPI Programming Tips for Signal Generators