Why the 630-Point Spline Pauses
The application builds one Spline from 630 Cartesian points and executes it with blocking move(). The controller must plan the entire path before motion starts. When the call finishes, the while(true) loop submits the same spline again, forcing another planning boundary and producing the restart delay.
Replacing spl() with lin() does not remove the large point count or the blocking resubmission boundary, which explains why that change did not improve the result.
Remove Conflicting Motion Constraints
The spline requests a Cartesian velocity of 900 mm/s while limiting relative joint velocity to 0.70. This combination can make path optimization more computationally demanding, and the available evidence indicates that 900 mm/s is unlikely to be reached on this path. Test a lower Cartesian command, starting at 100 mm/s or less, and remove the spline's setJointVelocityRel() constraint during diagnosis.
| Current setting | Diagnostic change | Purpose |
|---|---|---|
| 630 spline points | Reduce the point count; retain at least 2–3 mm between points | Reduce planning work without materially changing a smooth circular path |
setCartVelocity(900) |
Test 100 mm/s or lower | Reduce conflict between requested Cartesian speed and achievable joint motion |
setJointVelocityRel(0.70) |
Remove it for the first test | Eliminate the additional joint-speed constraint from the optimization |
The initial PTP code calls lbr.move(ptpStartingPos) before ptpStartingPos.setJointVelocityRel(0.25). Set the velocity before submitting the PTP if the 0.25 limit is intended to affect that move.
Queue Motion Before the Current Path Ends
move() blocks until the spline completes, so the next command cannot be submitted early enough for interpolation across the boundary. Continuous motion requires the following path to be available before the active path finishes and requires blending; without blending, the robot stops at each boundary.
Supported approaches are to divide the trajectory into smaller splines and combine them in a motion batch, or use moveAsync() with a MotionPathCondition that signals shortly before completion. Do not submit unrestricted asynchronous motions from a tight infinite loop; coordinate each submission with motion completion or the path condition.
Recommended Test Sequence
- Move
ptpStartingPos.setJointVelocityRel(0.25)before the initiallbr.move(ptpStartingPos)call. - Reduce the trajectory from 630 points while maintaining at least 2–3 mm between consecutive points.
- Set Cartesian velocity to 100 mm/s or lower and temporarily remove
setJointVelocityRel(0.70)from the spline. - Measure initial planning time and confirm that the reduced path still represents the required planetary motion.
- Split the path into smaller spline sections, enable blending, and queue sections using a motion batch or coordinated
moveAsync()calls. - Verify that velocity remains continuous at each section boundary and that the Cartesian impedance mode remains active throughout the queued motion.
FAQ
Why does an LBR iiwa pause before executing a spline?
A 630-point spline requires substantial planning before execution. Reduce the point count, keep approximately 2–3 mm between points, and retest at 100 mm/s or lower.
Why does the planetary spline stop on every while-loop cycle?
move() blocks until the motion ends, so the next spline arrives too late for interpolation. Queue the next section before completion and configure blending at the boundary.
Should continuous LBR iiwa motion use moveAsync or a motion batch?
Either can support queued motion: combine smaller blended splines in a motion batch, or coordinate moveAsync() with a MotionPathCondition. Avoid issuing asynchronous commands continuously without waiting for a defined condition.