Motion and position

Position only makes sense inside a coordinate system

“Move the slide to 250” is incomplete. Is 250 measured in millimetres, encoder counts or motor revolutions? Where is zero? Which direction is positive? Does the instruction refer to the commanded position or a measured position? A motion program becomes understandable when those questions have explicit answers.

Consider a small positioning table with useful travel from 0 to 400 millimetres. The gripper approaches a workpiece at 250 millimetres. The engineering specification should identify the reference point, units, travel limits, permitted speed and acceleration, and what establishes that the coordinate is trustworthy.

The PLC's ordinary motion logic is not a safety-rated motion function. Guards, emergency stops, safe speed and protective limits require appropriate hardware, architecture and validation. A browser model can teach coordinates and command lifecycles; it cannot certify a real machine's stopping behaviour.

Homing is an evidence-gathering procedure

An incremental encoder usually reports relative movement from a starting count. After a restart, the controller needs an agreed way to relate that count to the machine. A homing procedure may approach a reference switch, reverse off it, capture a defined edge or marker, and apply an offset. The selected drive and motion library determine the actual sequence.

An absolute encoder can preserve a position relationship, but it does not remove every commissioning or recovery question. Mechanical changes, encoder replacement, coupling slip and lost configuration can invalidate the assumed reference. Separate “the drive has a number” from “the machine accepts that number as its coordinate.”

Record homing completion and why it can become invalid. Do not let an HMI button simply set Homed := TRUE because an operator knows roughly where the slide is. A deliberately designed reference-setting procedure is different from bypassing the evidence.

A motion command has a lifecycle

PLCopen defines a family of motion-control interfaces, including standard concepts for command execution and results. Vendor implementations and supported features still need their own documentation. Use the PLCopen motion-control overview to understand the family, then check the block you actually use.

For a typical execute-triggered absolute move, your sequence must distinguish acceptance, ongoing work, successful completion, abortion and error. A false Busy signal is not sufficient evidence of success. It can be false before a command starts and after an error.

Beckhoff's MC_MoveAbsolute documentation illustrates this distinction with Busy, Active, Done, CommandAborted and Error. It also documents how new jobs interact with an active block. Read the command lifecycle and parameter rules.

Design the sequence before the block call

A useful sequence has these states:

Latch the target when accepting a request. If an HMI edits its numeric field during motion, that edit should become a proposal for a later move unless live retargeting is explicitly required and supported. Otherwise the phrase “this move” has no stable meaning.

Call the vendor block cyclically according to its documented requirements. Generate the execute transition deliberately, and allow the block to return to its ready condition before using the same instance for a new request. Keep the axis reference and command ownership clear: two sequences should not unknowingly issue conflicting commands to the same axis.

This is an illustrative call excerpt, not a complete axis project. Axis setup, types, library installation, command arbitration and error recovery must be supplied for the chosen platform.

MoveToStation(
    Axis := TransferAxis,
    Execute := IssueMove,
    Position := AcceptedTarget_mm,
    Velocity := AcceptedSpeed_mm_s,
    Acceleration := AcceptedAccel_mm_s2,
    Deceleration := AcceptedDecel_mm_s2
);

The interface looks short because the difficult decisions are outside the call. A professional program makes those decisions inspectable instead of hiding them in unrelated button handlers.

Predict whether the requested move is plausible

Suppose a slide moves 300 millimetres from rest, with maximum speed 200 millimetres per second and acceleration and deceleration both 400 millimetres per second squared. Time to maximum speed is 200 / 400 = 0.5 seconds. Distance during acceleration is 0.5 × 400 × 0.5² = 50 millimetres; deceleration uses another 50.

The remaining 200 millimetres at 200 millimetres per second takes one second. Total ideal motion time is two seconds. This is a trapezoidal velocity profile without jerk limiting, delays or settling. A real configured profile may take longer.

For a 40-millimetre move under the same acceleration limit, there is not enough distance to reach 200 millimetres per second. The ideal symmetric triangular profile peaks at sqrt(400 × 40), about 126.5 millimetres per second. Short moves are often acceleration-limited rather than speed-limited. Increasing the maximum velocity may therefore change nothing.

Completion is more than a coordinate comparison

Writing ABS(actual - target) < tolerance alone can report completion while the slide passes through the target at speed. Use the motion system's documented completion result and any additional process evidence required, such as settling, a clamped workpiece or a downstream position check.

Also distinguish following error from positioning tolerance. Following error compares commanded and actual motion during execution; a final acceptance tolerance describes the result the process needs. They may use different limits for different purposes. Do not relax a drive's following-error supervision merely to hide a jam.

Test missing reference, target outside permitted travel, command refusal, timeout, aborted move and feedback loss. For each, specify what the next legal operator action is. “Fault” without a recovery path leaves the machine waiting for somebody to edit internal bits.

Try it

A loader issues a move to 250 millimetres and waits until Busy = FALSE, then closes a clamp. On the first attempt the drive rejects the move because the axis is not referenced. Explain the failure and propose a better completion contract.

Work through the answer

The rejected command may never enter a busy state. The loader interprets “not working” as “finished successfully” and closes the clamp at the wrong position. Require a valid reference before acceptance, then associate the issued command with its result. Advance only on successful Done; route Error and CommandAborted to explicit recovery states, preserving their diagnostic information.

For the process itself, also require whatever evidence makes clamping appropriate: accepted target, valid feedback and any relevant settling or workpiece condition. Do not add a blind delay and call it fixed. A delay changes when the wrong assumption is used; it does not supply the missing evidence.