An automated resistance test may return an overload code, an empty response, or a nonfinite number instead of an ordinary reading. Those outcomes need explicit handling. Treating every unexpected value as zero can create a false short-circuit diagnosis, while treating it as an arbitrarily large number can create an unjustified pass.

The Python mathematical functions reference documents separate checks for finite numbers, infinity, and NaN. Other runtimes have their own behavior, so validate the actual language and test framework used by the station rather than assuming that a familiar comparison expression handles every special value.

Classify the response before applying limits

Keep the raw response and its communication status. Next, check whether the message is complete and follows the instrument’s documented format. Only then interpret its value and status. A number parsed successfully from the beginning of a truncated message is not necessarily a valid measurement.

Define the meaning of each documented special response for the exact function and range. Overrange may indicate a quantity beyond the selected measurement range; it does not automatically prove an open circuit or compliance with a product requirement. An invalid calculation inside the test application needs a different diagnosis from an instrument-reported overload.

Input condition Required decision
Finite reading with valid acquisition status Apply the approved numerical comparison
Documented overrange indication Use the approved overrange procedure
Missing or malformed response Record incomplete measurement evidence
Unexpected nonfinite calculation Investigate calculation inputs and configuration

Exercise the exceptional paths

  1. Inject representative valid values into the processing layer.
  2. Test empty text, invalid text, special values, and truncated responses.
  3. Confirm that each condition produces the intended status and explanation.
  4. Check that exports preserve missingness without substituting a plausible number.
  5. Verify that a retry creates a new linked attempt.

Perform these software checks independently of physical fault insertion. Do not create an unsafe electrical condition merely to produce a particular parser response. When hardware verification is necessary, use an approved simulator or safe reference setup.

Make the disposition visible

The operator needs to know whether the board failed a requirement or the station failed to obtain valid evidence. Keep that distinction in both the live display and the stored report. A dashboard that counts all unknown conditions as product failures distorts yield analysis and directs troubleshooting toward the wrong cause.

For a condition that can legitimately support acceptance, document why the instrument indication establishes the required bound under the selected configuration. Otherwise hold the decision until a valid measurement is available. The test-step status guide explains how to retain that distinction throughout the unit record.

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