Defining safe startup and restart behavior for a multi-axis fixture

A fixture can reconnect to its controller before it is ready to resume work. Power restoration, application restart and recovery from a motion fault are different events, each leaving different uncertainties. Write the expected restart states before commissioning so that “connected” never becomes an accidental synonym for “ready to move.”

List the events that interrupt confidence

Begin with ordinary startup, host-software restart, controller restart, communication loss, protective-device activation and mechanical intervention. For each event, ask what remains known about the fixture, coordinate reference, process outputs and queued actions. Avoid assuming all interruptions erase everything or preserve everything.

The Zaber protocol manual distinguishes reference validity from ordinary device status. It is an example of state information to investigate, not a supplied restart design for PositioningStages products.

Include changes that occur while the software is unavailable. A specimen may have been removed, a fixture replaced or a service cable repositioned. Restoring the previous screen values does not verify that the physical setup still matches them.

Define readiness in layers

A proposed state model can separate communication available, configuration identified, reference valid, fixture verified and process ready. These are requirements labels, not executable controller states. The integrator must map them onto the actual hardware and software evidence.

For every transition, specify what must be checked and who or what may authorize it. Some checks can be automatic if the required evidence exists; others may need a controlled operator confirmation. An operator should not be asked to confirm an invisible electrical condition that the design ought to monitor.

Pay particular attention to queued motion and process outputs. Ask whether an interrupted command remains pending, whether reconnection can resume it, and how acquisition or other process equipment is prevented from acting on stale state. Require documented behavior instead of inferring it from a successful demonstration.

Startup-and-restart checklist

• Identify the interruption type and retain the original event record.
• Confirm the expected device identities and approved configuration revision.
• Determine whether coordinates and fixture offsets still have a valid physical basis.
• Reconcile pending commands, process outputs and incomplete measurements.
• Verify the relevant fixture and payload condition through the approved method.
• Require the reviewed protective and clearance conditions before any recovery motion.
• Establish a new process checkpoint and record the release decision.

This checklist does not define a safety-rated control system. Protective functions, emergency behavior and restart permissions require a qualified machine-level risk assessment and the applicable equipment documentation. Do not bypass an interlock to make the checklist easier to complete.

Hypothetical host restart during an XY task

Imagine a two-axis fixture that positions a sample beneath an instrument. The host application closes after sending a move but before recording its completion. When it reopens, the device is reachable and the screen restores the last recipe.

The proposed restart design should first reconcile the unfinished operation. It should also establish whether the sample is still installed and whether the coordinate frame remains valid. Only then can the approved recovery path be selected. Automatically repeating the last move or homing every axis would skip those questions.

No specific recovery movement is prescribed here. The appropriate order depends on the fixture geometry and the actual controller’s documented behavior. A path that is clear for one axis arrangement may be obstructed in another.

Prove the transition rules

Review each interruption case using a suitable controlled test or simulation. Check not only the final screen message but the sequence of permissions, outputs and recorded evidence. Preserve discrepancies as engineering issues rather than adding undocumented operator habits to the process.

Keep the restart requirements with the multi-axis mechanical assembly records, host software version and acceptance plan. If a new fixture, controller revision or process instrument changes an assumption, revisit the affected transitions. A useful restart design gives the next operator an understandable route from uncertainty to verified readiness, while leaving protective decisions with the properly engineered machine system.

Document the person responsible for each unresolved readiness condition, so recovery does not depend on informal knowledge held by the original commissioning engineer.