Open-loop missed steps: detection and recovery requirements

An open-loop program can finish sending its commands even when the mechanism has not completed the intended movement. The engineering question is therefore broader than whether missed steps are possible. Define how a loss of confidence will be recognized, what work becomes invalid and how the fixture can return to a known state without creating a second problem.

Start with the observation boundary

Draw the signals available to the application: commanded position, controller status, physical sensors and any independent process measurement. Label which signals directly observe movement and which report software state. If no measurement observes the driven position, do not label a command counter “actual position” in the acceptance report.

The Zaber stall article describes encoder-based detection for applicable devices. It is a bounded example of how detection can depend on hardware. It does not establish that a listed PositioningStages model or an unspecified controller detects missed steps.

Ask the integration provider which faults can be detected, under what conditions and with what limitations. A claim such as “stall alarm available” needs a documented signal source and behavior, including what happens to the coordinate reference after the alarm.

Define position confidence and data validity

Create a simple requirements distinction between a valid reference, a suspected position discrepancy and a reference that must be re-established. Give each transition an observable trigger. Relevant triggers may include a documented fault indication, failed independent position check or an interruption whose effect on position is unknown.

Then connect those states to the process. If an inspection uses assumed position to label measurements, a suspected discrepancy can affect more than the next move. Specify how to identify and quarantine data collected since the last trustworthy checkpoint. Do not silently attach fresh coordinate labels to measurements whose original location is uncertain.

Avoid promising that every small loss of motion will be detected. If detection coverage is incomplete, record that limitation and decide whether the process can tolerate it. Some applications need additional observation rather than a more elaborate software exception handler.

Detection-and-recovery checklist

• List available position observations and the hardware that generates each one.
• Distinguish detected faults from plausible undetected position errors.
• Define the last trustworthy checkpoint for both motion and process data.
• Specify which pending commands and measurements must be suspended after uncertainty.
• Identify who may authorize recovery and which clearances must first be reviewed.
• Require the documented reference-establishment method and a verification step.
• Preserve the original fault record, recovery record and affected sample identifiers.

Do not test detection by obstructing an axis, defeating a limit or forcing an unsafe load. Use approved simulation, diagnostic methods or a qualified test procedure appropriate to the actual machine.

Hypothetical interrupted inspection

Imagine a fixture indexing a specimen through twelve measurement locations. After the seventh location, a controller warning appears and an independent checkpoint cannot confirm the expected position. The application should not assume that locations eight through twelve can proceed using the original coordinate count.

Under the hypothetical acceptance plan, the sequence pauses, unresolved data are marked, and the operator follows an approved recovery assessment. A valid reference and checkpoint must be restored before a new measurement segment is released. The team records whether measurements since the preceding checkpoint need to be repeated.

This example intentionally does not prescribe a home move, reverse move or automatic retry. Any such movement depends on fixture clearance, the fault cause and the manufacturer’s instructions. Recovery logic must not turn a diagnostic uncertainty into uncontrolled motion.

Make recovery an acceptance deliverable

Ask for a written account of expected fault messages, coordinate validity and process-state transitions. Review it alongside the mechanical shortlist and the specification basis. Neither a repeatability rating nor a successful demonstration under one load proves detection coverage for every abnormal event.

Acceptance should establish that known fault cases produce the intended application response, affected data can be identified, and recovery leaves an auditable new starting point. Unresolved detection gaps should remain visible in the final requirements package. The objective is a process whose evidence survives an interruption, not merely a program that restarts without displaying an error.