Live Weld Speed Control

Built a distributed real-time speed control system allowing operators to modify weld speed while the robot is actively welding — changes propagate through a 3-layer gateway (Vue.js tablet → Python executive → C++ EtherCAT master) with step-based trajectory filtering that ensures only weld segments are modified. Too fast = cold weld defect. Too slow = burn-through and melted equipment. Wrong segment = collision. The same distributed motion planning patterns used in autonomous vehicle pipelines.

Implemented a step-based trajectory filtering algorithm (_get_scope_weld_ids()) in the Python executive interpreter that isolates which trajectory segments are safe to modify during live execution. The algorithm walks backward through the weld program's step list from the current step_id to find the most recent WeldStart or ChangeRecipe boundary, then walks forward to collect all Weld-type step IDs until the next ChangeRecipe boundary. Only these weld step IDs are passed to the C++ trajectory modifier — Move, approach, and retract segments are explicitly excluded. Edge case handling: when step_id points at a recipe step (the "upcoming" recipe rather than the current one), the search starts one step back to avoid including the wrong recipe scope.

Built SplinedTrajectory::setWeldSpeed(speed, step_ids) in the C++ EtherCAT master that modifies trajectory parameters during live execution at the 1kHz control loop level. The method iterates all trajectory segments in the active spline, checks each segment.endPoint_.step_id against the allowed step_ids list, and only modifies matching segments' speed_limit field. Connected through a 3-layer ROS service gateway: the Vue.js tablet fires /set_weld_speed with absolute speed in mm/s and the filtered step_ids array → the Python executive gateway routes to the active Job process → the Job handler updates the recipe's weld_speed field AND calls the C++ EtherCAT master's service to modify the live trajectory.

Fixed a critical production bug where pausing and resuming a weld caused the travel speed to drop to approximately 10% of the intended value, causing the welding torch to linger on the workpiece and melt nozzle guards — physical damage to equipment. Root cause: a hidden speed slider in the tablet UI retained its value from a previous Fast Preview run. When the operator paused and resumed the actual weld, the resume code read the speed multiplier from this stale slider state (base_weld_speed_) instead of the active weld speed. Fix: replaced the multiplier-based speed system with absolute speed values in mm/s stored in the recipe, eliminating any dependency on transient UI state.

Implemented torch delay logic for weld resume after pause — a safety requirement because the robot must first rejoin the weld path before the welding arc can be restarted. The system detects REJOINING_PATH status in WaypointEvents.on_trajectory_feedback, sets an _awaiting_on_path flag for deferred torch activation, and only enables the torch when the trajectory feedback reports the robot has returned to the weld path. Without this delay, the robot would fire the welding arc during the repositioning move, potentially welding in the wrong location or damaging the workpiece.