Motor Control Engineer Guide to an FCT Specification for Production

Prepared and technically reviewed by the Sankey Engineering Team. Updated August 26, 2026.

Evidence notes for an engineering review

Capture the measurement setup in enough detail for another engineer to reproduce it: controller and motor revision, supply source, load or emulator, mounting, harness, ambient, instrument, firmware or parameter set, and stabilisation rule. Note both the observed result and the interpretation. If a result is exploratory, label it as such rather than turning it into a production limit. This discipline is especially important when a controller is tuned for one motor sample and later evaluated with a supplier revision.

When a defect is found, preserve the initial state and collect the smallest controlled change that can distinguish motor, firmware, hardware, fixture, and installation causes. Re-run the affected state after the change and record whether the improvement introduced a new thermal, EMC, protection, or service risk. The final release should link the engineering evidence to the production check that will detect a repeatable unit-level failure.

• Configuration and setup are traceable
• Acceptance criteria are observable
• Exploratory data is not mislabelled as a limit
• Failures retain a reproducible state
• Retest decisions follow revision control

A production functional test specification should be precise enough for an operator and useful enough for an engineer investigating a failure. This guide shows how to separate design-validation evidence from repeatable FCT coverage for motor-control PCBA.

Identify the tested configuration

State the board revision, firmware or parameters, motor or load emulator, supply, harness adapter, fixture revision, and instrument method. Link each result to a unit identifier and station.

Without configuration identity, a passing record may be impossible to reproduce. Make the approved setup visible at the beginning of the specification and in the station workflow.

Write actions and pass criteria

Each row should define initial state, operator action, expected motor or output response, timing or measurement where approved, and failure handling. Replace phrases such as “normal operation” with observable results.

Use limits that belong to the product and test method. If a value is still an engineering investigation point, keep it out of the production criterion until the responsible team approves it.

Cover protection and interfaces

Include safe power-up, command inputs, speed or direction functions, feedback indication, light or accessory outputs, and approved fault response. Do not energise an unsafe condition merely to prove a protection circuit.

Fixture design should prevent incorrect connections and make a failed state safe to retain. The FCT should test the functions that matter to the released product, not every possible laboratory experiment.

Control failures and changes

Define stop, quarantine, rework, retest, and escalation paths. Store board identifier, firmware, fixture, operator or station, date, result, and failure code according to the quality plan.

A motor, harness, firmware, component, or fixture revision can invalidate an FCT assumption. Link change review to the test specification and station release.

Frequently asked questions

Does FCT replace ICT and AOI?

No. ICT, AOI, FCT, incoming inspection, and engineering validation cover different risks and should be assigned by the quality plan.

Can a generic motor be used in production FCT?

Only if the project approves it as a representative load or emulator and defines the equivalence and limits.

For a project-specific review, send Sankey your motor, load, interface, target market, and volume requirements. Review the relevant Sankey solution area before preparing a quotation request.