An instrument timeout means an operation did not complete within its configured wait boundary. It does not establish whether the device executed the command, produced a result, or left a partial response in transit. Recovery must resolve that uncertainty before another result is assigned to a board.
NI’s VISA timeout guidance describes the timeout as a maximum wait for a request in a session. Increasing that value may address a legitimately long operation, but it does not repair incorrect framing, missing triggers, or a confused command-response sequence.
Capture the failed exchange
Record the instrument identity, operation, expected response, received bytes if any, timeout setting, and relevant acquisition configuration. Distinguish a failure while writing from a failure while reading. Preserve the board identity, test-step identity, and attempt number associated with the interrupted exchange. Note whether the test software changed the timeout during the sequence; a setting that was adequate for a short query may be unsuitable for a later buffered acquisition.
Determine whether the command is safe to repeat within the test method. A request for a stored reading and a command that changes output or starts a new acquisition have different consequences. A generic retry wrapper can repeat an action that was already performed even though its acknowledgement was lost.
Re-establish a known state
| Uncertainty | Recovery question |
|---|---|
| Partial response | How is the message boundary restored? |
| Acquisition still active | How is completion or cancellation confirmed? |
| Unknown configuration | Which settings must be read back or reapplied? |
| Old result available | How is it distinguished from the next acquisition? |
Use the instrument’s documented recovery behavior. A buffer-clear operation, status clear, acquisition abort, and full reset are not interchangeable. Each may discard different evidence or change different parts of the device state.
Bound and record the retry
- Mark the interrupted attempt as incomplete.
- Perform the defined recovery sequence.
- Confirm the conditions needed for a fresh measurement.
- Start a separately identified retry.
- Store its result without overwriting the failed attempt.
Test recovery using controlled failures during development. Include a delayed response, a partial response, and a missing trigger where the equipment supports safe simulation. Verify that no earlier result can be reported as the current board’s measurement.
If recovery cannot establish a known state, stop the affected test path and report that condition. Continuing with an uncertain measurement can create convincing but incorrect pass records. The response framing guide helps separate transport boundaries from the measurement’s own completion state.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist