How do you test motion control in custom machines before FAT?

A PLC connection only shows that tags can move between the controller and the twin. A motion test asks whether the model answers commands with the timing, states, limits, and faults the production sequence expects. That stops a smooth animation from being treated as proof that commissioning is done.

Use the PLC platform guide for controller setup, communication, and tag mapping. Use this guide to decide how detailed the model needs to be, which commands and feedback the axis must have, how you test restart after a fault, and what still belongs on physical FAT.

The twin should react to commands such as enable, home, move, halt, abort, and reset. It should report standstill, homed, busy, in position, aborted, and error. It must not hide a bad command or report success after a collision or after a limit is passed.

Choose the detail per test, not as one level for the whole project. Signals with no movement can be enough to see whether the sequence takes the right path. You need positions and zones in the model when the result depends on reach, clearance, or several axes hitting each other in time. A model with forces, or hardware in the loop, only pays off when load, controller timing, or a specific drive behaviour is part of what you must prove.

Write the chosen level and what it does not cover into the test. If backlash, resonance, thermal drift, or torque response is not in the model, do not treat the result as proof of those things.

Keep what you ask the axis to do separate from what it actually reports. Commands can include power or enable, home, an absolute or relative move, halt, abort, and reset. Parameters can include target position, velocity, acceleration, deceleration, and jerk. Feedback should include actual position, standstill, homed, busy, in position, aborted, error, and an error ID.

Take a multi-axis transfer as an example. MoveAbsolute sets busy, position moves through the model, and in position only becomes true inside the agreed tolerance. If a guard or interlock changes, or a software position limit is passed, the model reports the matching fault or abort. The sequence then has to follow the documented reset or home again.

That is less than a full drive emulator on purpose. You reproduce the interface the PLC uses, without claiming that drive tuning or motor physics are in the model.

Restart after a fault is where hidden assumptions in the motion sequence usually show up. For each test, write the starting condition, the fault you put in, the expected order of feedback, what the operator is allowed to do, and the safe end state. Judge the result from the signals, not from the animation.

A short set you rerun after every relevant change should cover lost home, move timeout, abort during motion, a software position limit, drive not ready, in position that never arrives, a robot handshake timeout, a CNC cycle abort, and restart after an emergency stop.

If a command is impossible, make that visible. Reject it, set a defined error, or report collision and limit. Quietly changing the target can hide the same defect that later stops the physical machine.

On a robot cell the PLC usually exchanges mode, zone, permission, start, busy, complete, and fault with the robot controller. A simplified moving model can test that handshake when paths and robot-specific logic are out of scope. You need current cell geometry when reach or clearance is the question.

On a CNC station, model the line handshake: ready for load, clamped, cycle start, cycle active, cycle complete, alarm, and reset. Do not simulate G-code or cutting unless a specific acceptance test depends on it.

Robot and CNC program versions still matter. Tie the interface test to the PLC version, parameter set, robot or CNC program version, twin version, and signal list, so a timing change cannot pass against an old baseline.

Keep four things separate. Hardware travel limits come from physical switches or drive inputs. Software position limits are configured positions that make the controller or drive react. Zones describe allowed or forbidden geometry. Safety functions such as STO, SS1, SOS, or SLS have defined behaviour in the safety system.

The twin can run the standard control sequence around these conditions and can report simulated status for testing. It does not prove certified safety hardware, how fast the machine stops, where guards sit, or the safety calculation.

Tie every modelled limit and zone to the drawing or parameter version it came from. When stroke, tooling, frames, or guarding change, the model and the affected tests have to change with them.

From the twin you should keep the interface definition, scenario inputs, expected and actual state changes, software versions, deviations, and pass criteria. Save enough to rerun a failed test after a PLC or model change.

Physical FAT still checks drive tuning, following error under load, backlash, mechanical tolerances, vibration, thermal behaviour, stopping, guards, sensors, wiring, and safety functions. The virtual result lowers integration risk. It does not prove things you never put in the model.

neexo writes motion and integration logic and connects it to a testable machine model. Who owns robot and CNC programming is agreed per project, together with what you expect from virtual commissioning and from physical FAT.