Verify Test-Sequence Cleanup After Errors and Operator Interruption

A test sequence often leaves equipment in a different state from where it started: outputs enabled, relays routed, sessions open, or temporary files pending. An interrupted sequence must account for those changes. A visible “stopped” message does not prove that the equipment reached the intended resting state.

NI’s TestStand run-time error guidance distinguishes running cleanup from aborting without cleanup. Review the actual behavior of every stop path in the chosen framework; similar-looking controls can execute different recovery logic.

Inventory state-changing actions

List the resources and physical states created during setup and measurement. Include instrument sessions, source outputs, switch routes, fixture controls, and unfinished result records. Define the desired post-test state for each, based on the fixture and product requirements.

Make cleanup conditional on what actually happened. If setup failed before a resource was opened, cleanup should not assume it exists. If only some channels were configured, the recovery path must still handle the channels that were changed.

Test each exit route

Exercise interruption at several points, including during setup and while cleanup is already running. A recovery function that works only after a fully completed test is insufficient. Use controlled conditions and appropriate fixture protections when validating these paths.

Handle cleanup failure honestly

1. Attempt the defined recovery actions in the required order.
2. Record the result of each important state change.
3. Continue independent cleanup actions when appropriate.
4. Mark any unconfirmed state clearly.
5. Prevent a new run from assuming successful recovery.

Do not let one failed session-close call silently skip every remaining recovery action. Conversely, avoid reporting that outputs are off merely because the software sent a command. Use the confirmation method appropriate to the equipment and the test’s requirements.

Preserve the primary failure and any cleanup failures separately. The original product or instrument problem should not disappear beneath a later exception from the recovery routine. This distinction helps maintenance identify what started the event and what prevented orderly recovery.

Software cleanup is part of a defined fixture operating process. It is not a substitute for hardware protections required by that fixture. The practical release evidence is a record of tested stop paths and their observed final states, including known limits when communication or execution is lost.