Validate External Limit Lookup Before Evaluating a PCB Measurement

Moving test limits into a database or property file makes maintenance easier, but it creates another dependency in the pass/fail decision. A successful query does not prove that it returned the correct limits. Validate the lookup key, selected revision, and completeness before evaluating measurements.

NI’s Property Loader example demonstrates loading step limits and other values from a database. In a production implementation, the important question is which records are loaded for the specific board and test attempt.

Define a complete selection key

Identify the product, hardware or assembly variant, test step, applicable recipe, and limit-set revision. Include operating condition where one step name can be evaluated under several states. Avoid a lookup that selects the first row matching a broad product family.

State how effective dates or release states are used. A newly drafted limit record should not become active merely because it has the latest timestamp. Preserve the distinction between available data and approved data.

Validate the resolved limits

Check the values after loading, not only the database record. A conversion, property-name mismatch, or later initialization step can change the effective values used by the test. Store the resolved limit identity with the measurement result. Check that a disconnected database does not leave the preceding product’s limits in memory, particularly when two product families run consecutively on one station.

Challenge lookup failures

1. Run a known supported configuration.
2. Request an intentionally missing configuration.
3. Introduce a duplicate candidate in a test dataset.
4. Exercise an invalid unit or inverted limit range.
5. Verify that no unsupported case silently passes.

Do not substitute a broad default for a missing required limit without an explicit engineering rule. A fallback intended for development can otherwise allow a new production variant to run with inappropriate criteria. Keep optional defaults distinguishable from required acceptance data.

Retain an immutable reference or snapshot of the applied limit set. If a database row is edited later, historical records must still explain the decision made at the time. Storing only the current table name is insufficient.

The final test record should allow a reviewer to reconstruct the measured value, its interpretation, and the exact acceptance rule. Externalizing limits is useful when it improves controlled maintenance without weakening that traceability.