Request result()
After the measure() function has triggered the data acquisition process, request_result() is called to query the results, which are retrieved by read_result() in the next step.
Functionality
Within the concept of unblocking parallelization, the methods request_result() and read_result() are designed to improve measurement efficiency by allowing instruments to operate concurrently.
request_result(): This function sends a command to the instrument to initiate data acquisition or buffer filling. It is typically non-blocking, meaning it does not wait for the operation to complete. This allows multiple instruments to start their operations in parallel.
read_result(): This function retrieves the result from the instrument. It includes any necessary waiting time until the buffer is ready to be read. It is usually called after all instruments have been triggered withrequest_result().
By separating the triggering (request_result()) and reading (read_result()) phases, SweepMe! enables instruments to fill their buffers in parallel. This parallelization significantly reduces total measurement time.
If blocking (e.g., waiting for the buffer to be ready) occurs within request_result(), other instruments might not yet have started their acquisition processes. As a result, measurements would proceed sequentially rather than in parallel, which increases total execution time.
Therefore, in general, a command is sent in request_result() to instruct the instrument to start filling the buffer, and the result is read later in read_result(), once it's ready.
Driver Development
- Measurement Modules:
The `request_result()` function is typically used after the measure() function has been called for measurement modules that expect longer measurement times, such as Temperature modules. It enables parallel measurements between instruments in the sequencer.
- Multi-Channel Devices
When using devices with multiple channels that communicate through the same port, special care must be taken. This applies, for example, when sending commands such as: self.port.write("MEAS:CHANNEL 1?").
Some devices do not append results to the output buffer when sending readout commands for multiple channels. This can result in timeout errors if the query and the buffer readout are executed in two separate phases, such as request_result() and read_result().
For example: self.port.write("MEAS:CHANNEL 1?") followed later by: self.port.read()
In such cases, reading out the first channel may work correctly, but attempting to read a second channel can result in a timeout error because no additional data has been appended to the buffer. To avoid this issue, the request and readout should be performed in the same phase using: self.port.query("MEAS:CHANNEL 1?") This ensures that the command is sent and the corresponding response is read immediately, preventing buffer synchronization problems.
Alternatively, a master channel can be assigned to send a combined command: self.port.write("MEAS:CHANNEL 1?;MEAS:CHANNEL 2?;MEAS:CHANNEL 3?") and share the results via self.device_communication.
- Not for Switch Drivers:
The `request_result()` function is not necessary for drivers like Switch, which are used to set values rather than acquire data. These drivers do not require data readiness checks.