Sequenced motion versus coordinated motion: specifying the difference

“Move X and Y” can describe several different requirements. One process needs X to finish before Y begins. Another allows both axes to move independently toward their destinations. A third needs their positions to follow a defined relationship throughout the move. These cases should not share an ambiguous line in an RFQ.

Describe what matters between destinations

For sequenced motion, the order and completion conditions are central: one action releases the next. For coordinated motion, the path relationship also matters while the axes are moving. Reaching the same final coordinates does not prove that two systems traced the same route.

Write the process requirement in physical terms. An inspection fixture that acquires only at stationary points may primarily care about endpoint placement and clearance. A process that acts continuously along a curve may depend on path shape, speed and synchronization throughout the movement. The machine designer still needs to assess the path in either case.

Do not infer coordination from an XY mechanical assembly. The multi-axis catalogue describes mechanical configurations. It does not document a supplied interpolation engine or guarantee a coordinated-motion interface.

Identify the controller evidence required

Ask whether the proposed controller supports the necessary axes together, the required path primitives or trajectory representation, and the relevant timing behavior. Request exact model and firmware documentation, including restrictions. Starting two independent commands close together is not evidence that their trajectories remain coordinated.

The Zaber protocol manual documents streamed path commands for applicable devices. That is a third-party implementation example, not an interface available by implication on this catalogue.

Also ask what happens at segment boundaries, interruptions and buffer starvation. A controller that accepts a list of points still needs a documented interpretation of how to traverse them. Do not invent behavior from a file format or marketing term.

Sequencing-or-coordination checklist

• State whether the process acts only at destinations or during movement.
• Draw the required route and any prohibited regions between destinations.
• Identify axes whose positions must maintain a defined relationship.
• Specify endpoint, path and timing requirements separately.
• Request controller documentation for the exact trajectory functions needed.
• Define the expected response to incomplete trajectory data or an interruption.
• Assign a representative path-verification method under the intended fixture load.

The checklist should produce a testable requirement, not simply the word “synchronized.” Include which point on the fixture follows the path and which coordinate frame defines it.

Hypothetical rectangular versus diagonal route

Suppose an imaginary fixture must travel from one corner of a rectangle to the opposite corner. Moving X first and Y second traces two sides of the rectangle. A coordinated straight-line move would follow the diagonal. Both can reach the same endpoint, yet their clearance and process consequences differ.

If a tall obstruction occupies the middle of the rectangle, the diagonal might be unacceptable even though the endpoints are clear. Conversely, a process that must follow a diagonal feature cannot be satisfied by the two-leg route merely because the final coordinates match.

The review therefore records the required route before choosing hardware or writing commands. These geometric examples do not establish that either movement is appropriate for an actual machine; the fixture drawing and risk review determine that.

Accept trajectory behavior separately from mechanics

The mechanical acceptance can cover mounting, travel and the specified positional characteristics. The control acceptance must cover the commanded path, sequencing logic and response to the relevant interruptions. A system-level test then establishes whether their combination satisfies the process.

Use independent measurement or another justified observation method where path performance matters. A log of requested waypoints is evidence of program intent, not proof of the physical trajectory. Record measurement conditions and the interpretation of any reported following error, since definitions vary by controller and test method.

Keep claims bounded to the reviewed configuration. The resulting document should let a buyer distinguish a mechanically suitable assembly from a complete trajectory solution, without treating either as inadequate simply because it serves a different requirement.

If the process changes from stationary inspection to action during movement, reopen the coordination requirement even when the same endpoint list is retained.