Case Study / 01
Multi-Axis Torque Test Firmware
Developed and refined firmware for a multi-axis automated test system, improving motion coordination, torque-data integrity, serial reporting, diagnostics, and fault recovery.
Overview
The engineering problem at a glance
- Challenge
- Torque readings could become unreliable when both axes attempted acceleration-window measurements at overlapping times. The firmware also needed clearer boundaries between valid measurements, missing samples, diagnostic output, test limits, and hard safety limits.
- My role
- Firmware, motion-control, diagnostics, and validation
- Key decision
- Only one axis should own the acceleration-window torque measurement at a time. The axes are coordinated so those measurement windows do not overlap on the single-threaded controller.
- 01AX90 sweep
- 02Measurement owner
- 03Torque capture
- 04AX155 sweep
- 05Structured result
01
System Purpose
The system uses a Teknic ClearCore controller and ClearPath servo motors to run two test axes, AX90 and AX155. Each axis performs defined sweep cycles, captures torque through HLFB feedback during acceleration, and reports structured test data through USB serial communication.
02
The Reliability Problem
The controller could receive no usable torque sample for AX155 when its acceleration window overlapped activity on AX90. Treating that condition as a numeric result would make the report look precise while hiding the fact that no valid measurement existed.
The broader firmware also had to distinguish test judgement from equipment protection. A part can fail a configured test limit without the same event being a hard machine torque fault.
03
Acceleration-Window Coordination
I treated torque capture as an owned resource. One axis is allowed to perform the acceleration-window measurement while the other axis remains outside its own measurement window. This makes data ownership explicit and keeps behavior deterministic on the single-threaded controller.
The change was made within the existing motion architecture, preserving working behavior while tightening the coordination between AX90 and AX155.
04
Serial Protocol and Diagnostics
I improved commands and structured responses for startup, diagnostics, runtime limits, home-reference behavior, fault clearing, and recovery. Valid measurements, diagnostic information, and missing samples are reported as different states.
When a valid sample is unavailable, the system reports NO_DATA rather than substituting a number that could be mistaken for a real result.
05
Fault and Recovery Behavior
Normal test limits and hard torque-fault limits were separated so result judgement and equipment protection remain understandable. Recovery commands and fault-clearing behavior were refined to support safer troubleshooting and restart paths.
06
Testing and Validation
Host-side C++ tests and Arduino/ClearCore stubs made important logic testable without requiring the physical machine for every check. Source review and compile checks supported the firmware changes, while final two-axis validation remains a hardware task.
Result
What the work changed
- More deterministic torque capture
- Clearer structured output
- Better diagnostics
- Cleaner fault and recovery behavior
- More maintainable firmware organization
- Improved host-side test coverage and documentation
Technology
Tools and disciplines
This public case study describes system behavior and engineering decisions without exposing proprietary source code or machine documentation.