Absolute and relative moves in a repeatable work sequence

Repeated motion is easier to review when a program clearly distinguishes destinations from displacements. An absolute move identifies a target in a defined coordinate frame; a relative move requests a change from the applicable starting position. Both can be useful, but their meanings must remain clear when a process is interrupted or a reply is lost.

Choose semantics from the process record

Use named absolute destinations when the process naturally refers to fixture stations, inspection features or parking locations in an established frame. Use relative displacement where the task intentionally advances from its current state, such as an operator-approved adjustment. Neither choice removes the need for a valid position reference and reviewed travel envelope.

The Zaber protocol manual documents absolute and relative movement separately. This article uses that distinction as terminology, not as a promise that a proposed controller accepts any particular command syntax.

Record the frame, units and direction beside every recipe value. A number without those fields is not a complete motion instruction. For multi-axis recipes, identify whether each target applies independently or forms part of a documented coordinated trajectory requirement.

Make completion a separate decision

Write down what “accepted,” “in progress” and “complete” mean in the selected interface. A valid request can be accepted before motion finishes. A completed motion report may still require a process-specific settling or measurement check before acquisition is allowed.

Give each application operation its own identifier, separate from whatever identifier the controller protocol provides. Preserve the requested target, the reply and the resulting state. This helps distinguish a rejected instruction from one whose reply was simply not received.

The critical retry question is whether the first request may already have executed. Repeating a relative displacement can add another displacement; even an absolute request should not be blindly repeated when the current machine state is uncertain. Define reconciliation using documented status and position evidence before deciding on another command.

Move-semantics checklist

• Classify each recipe entry as a destination, displacement or other documented operation.
• Include frame, units, axis identity and applicable configuration revision.
• Specify the observation that confirms command acceptance.
• Define the evidence required for motion completion and process readiness.
• Describe timeout handling without assuming that a timeout means no movement occurred.
• Require reconciliation before retrying an operation with uncertain execution.
• Store the operation identifier and result with the relevant sample or workpiece.

Review the checklist with both the software developer and the person responsible for fixture clearance. Correct arithmetic does not make an unsuitable path acceptable.

Hypothetical duplicate-request problem

An imaginary adjustment routine requests a positive displacement of 0.2 mm. The host does not receive a reply within its expected interval. If the axis already moved, issuing the same relative request again could produce 0.4 mm total displacement. These values illustrate transaction ambiguity and are not recommended settings.

A better requirements document says that the application enters an unresolved state, consults the documented device status and reconciles the operation before proceeding. If the evidence cannot establish what happened, the process follows its approved recovery procedure rather than guessing.

For comparison, a station-based recipe might specify an absolute destination of 12 mm in its released work frame. Retrying that destination does not inherently request another 12 mm increment, but it still requires a known reference and an acceptable route from the current state.

Test interruptions as well as normal cycles

Use a reviewed test environment to exercise delayed replies, rejected operations and interrupted sequences without bypassing protective functions. Confirm that the application preserves enough information to distinguish these outcomes. A successful uninterrupted demonstration is not a complete test of move semantics.

Keep the mechanical assumptions available through the stage selector and the applicable drawings. The resulting software contract should explain not only where an axis is meant to go, but how the application knows whether that operation happened. That is what makes a repeated sequence reproducible after an imperfect communication cycle.

Include this distinction in operator training and recovery screens, where an innocent-looking repeat button may otherwise conceal a second physical displacement request.