Synchronization

For the device to function properly, on certain points in the program it is very important that the device and the remote computer, where the program is running, are in synchronization. Basically sometimes the remote computer has to wait for the measurement device to catch up. These waiting times can vary in length and so it is best practice to let the device notify the remote computer when it has finished its operations. This is especially important when performing measurements or calibrations. There are several options to synchronize the remote computer and the device, that are listed in this chapter.

• operation complete query
• status byte polling
• wait command

Operation Complete Query

The operation complete query *OPC? is the easiest synchronization method. When calling *OPC? the device waits for all ongoing measurements to complete and only after that a 1 is returned as return value. So it basically delays the query response. The response itself is not needed at all, but the time waited for the response to arrive is important. Keep in mind to read the queries response, although the value itself is not needed.

There are two major disadvantages to consider that often outweigh the simplicity of the Operation Complete Query.

1. Communication Blocking: As the synchronization happens while waiting for a query response message, in this time the communication between the device and the programming computer is blocked. E.g. no status messages or other commands can be written to or read from the device.
2. Timeout: Generally, the query commands include a timeout (VISA-Timeout). The timeout defines the maximum time that can be waited for a query response. If no response is received in the given time range, a Timeout Error is generated. This is usually used to prevent a program from freezing and ensure the responsiveness of a program. However, if the given command takes longer, than the desired timeout settings, it is considered to either switch to option Synchronization or to adjust the timeout value (be careful with the second option as it can make your program unresponsive).

Status Byte Polling

A method that does not have these disadvantages that the *OPC? query has is the method of status byte polling. The basic concept is the following. We tell the device that it should notify us as soon as every command has finished. This notification means setting a bit in the status byte. So we poll the status byte in a continuos loop and check if the desired bit is set or not. In the time between two polling cycles, we are still able to get or send information from or to the device. There is also no timeout problem, because the status byte querying itself is fast and does not block the communication.

Note

For the understanding of this command it is important to know, how the status register system works. A brief summary can be find below, but if you are not familiar with the status registering structure, have a quick look at "The status registering model of a SCPI device".

Basically the Status Byte Register contains a summary of all the available status registers. The one that we are interested in for the purpose of this synchronization method is the Event Status Register (ESR). This register contains information about all the events and errors that occur. The Bit 0 is the bit for signalizing that an operation is complete. The Status Byte contains a summary of the Standard Event Status Register on Bit 5. Which bits of the Standard Event Status Register make it through to the Status Byte Register can be selected with the Event Status Enable (ESE) register which acts as a filter. If one of the ESR bits is set AND the corresponding ESE bit is set, the bit in the status byte is also set. Then we can check the status byte register. But keep in mind that reading the STB does not automatically clear the ESR register.

So the steps, that are needed are the following. See the table after the flow chart for an explanation.

	command	explanation
1	*ESE 1	Set the enable register so, that only the Operation Complete Events are represented in the status byte register.
2	*ESR?	Manually clear the ESR register by reading it. The value itself is not interesting.
3	TRIG:SING - or similar	Start a measurement or anything similar that runs in the background and takes some time. This is the command that should be awaited.
4	*OPC	Tell the device that it should set the operation complete bit of the ESR.
5	*STB? - or build in VISA command	Query the value of the Status Byte register.
6	check if bit 5 is set (language specific)	Check if the bit 5 is set (received value & 32 != 0). If it is set, the operation has completed; go to step 7. Otherwise the operation is still running. Wait some time and than check again (go to step 5).
7	*ESR?	Clear the event status register, to ensure that you do not leave any possible confusing data.

The advantages of this method is that it does not block the communication and you cannot run into a timeout error. The disadvantage is that this method is more complex compared to the first method explained.

Wait Command

The *WAI command per se is not exactly a command that can be used to synchronize the remote programming computer and the device, but it is also a way of ensuring that overlapped commands do not conflict each other. When calling the *WAI the device stops receiving new messages until the pending operations are completed. So you can assure that the command that follows a *WAI command does not interfer with other ongoing operations.

Keep in mind that the wait command blocks all further interactions to the device. The messages that are written to the stream or only read when the pending operations are finished. Thereforeuse *WAIT with caution.