Robot move time for small moves: acceleration beats speed

You command a 10 mm tracking move and the robot takes 0.46 s — the same time a 20 mm move takes. The cause is not the speed value but what surrounds it. On small moves the robot never reaches commanded speed, so acceleration, deceleration and the controller's per-move overhead set the clock. This guide gives you the triangular-profile math behind that 0.46 s, explains why a lower speed setting can beat a higher one, and puts the fixes in order — payload schedule, termination type, vision-loop latency — with the numbers to re-measure after each change.

Why does a 1 mm robot move take the same time as a 20 mm move?

Because neither move ever reaches commanded speed. On millimetre-scale travel the profile is all acceleration and deceleration, so a 1 mm move and a 20 mm move both land near your measured 0.46 s — the clock is profile overhead, not distance travelled.

A controller plans each move as accelerate, cruise, brake. Cruise exists only when the move is longer than the accel and decel travel combined. Shorter than that, the profile is a triangle: accelerate over half the distance, brake over the other half. The time then follows from acceleration alone:

Distances in mm, acceleration in mm/s², time in s. Assume a mid-range 3000 mm/s² for a 50 kg-class wrist with a light tool. The triangle then costs 0.04 s for 1 mm, 0.12 s for this move and 0.16 s for 20 mm; even across 1000-10,000 mm/s², the 1 mm triangle spans only 0.02-0.06 s. Your measurement says otherwise: 4 × 1 mm ÷ (0.46 s)² = 18.9 mm/s², and the 20 mm move at the same 0.46 s back-calculates to 380 mm/s². If move time were pure ramp, that implied acceleration would be constant. Instead it rises twenty-fold with distance — the signature of roughly 0.4 s of fixed overhead per move: profile shaping, braking reserve, settling and instruction processing that never touches the speed target.

Why is 1000 mm/s faster than 3000 mm/s for small moves?

Because the controller scales braking reserve and settling to the speed you command. Stopping from the top setting takes about 3 m of envelope at that acceleration, the lower one only 333 mm, and that overhead dwarfs the 6.7 ms of cruise the higher setting could ever return.

The controller plans each speed class with its own deceleration envelope and S-curve shape, tuned for the payload on the wrist. On a move with no cruise phase, those overheads scale up with the commanded speed while the thing they purchase — reaching that speed — never happens. The stopping distances make the point:

Corner blending adds a second penalty: the rounding radius at a continuous termination grows with v²/a, so at the top setting it reaches roughly 3 m — the controller must either round past the part tolerance or slow inside the move, and both cost more than the cruise they replace. That is why the lower setting wins. The fastest setting for small moves is found by measurement, not by the number on the speed line.

How much time can a higher speed setting actually save?

Almost none: on this short move, tripling the speed target can save at most 6.7 ms of cruise, while the profile overhead it changes is measured in tens of milliseconds.

Worked through:

1. Cruise time at the lower setting: 10 mm ÷ 1000 mm/s = 0.010 s = 10 ms.
2. Cruise time at the top setting: same distance ÷ 3000 mm/s = 0.0033 s = 3.3 ms.
3. Ceiling: 10 − 3.3 = 6.7 ms — and only if a cruise phase existed at all.
4. Triangle check at 3000 mm/s²: t = 2·sqrt(10 ÷ 3000) = 2·sqrt(0.00333 s²) = 0.115 s, with peak speed sqrt(10 × 3000) = 173 mm/s — 17 percent of even the lower setting, so neither command is ever reached.

Measured against that 0.12 s of physics, your 0.46 s leaves about 0.34 s of overhead per move. The speed target cannot touch it; the profile inputs in the next sections can.

What does the payload schedule change in move time?

The payload schedule — mass, center of gravity and inertia past the wrist — sets the controller's acceleration and deceleration limits. A schedule left stale after the camera went on is how a move back-calculates to 19 mm/s² instead of thousands.

When the schedule understates the tool, the controller brakes as if carrying inertia it cannot stop, so it softens both ramps. When it overstates, the ramps run conservative and slow. Both directions cost time on a triangle, and the second one also hides overshoot. Weigh the gripper, bracket, camera, cabling and heaviest part actually fitted, enter the mass, center of gravity and inertia the teach pendant asks for, then re-run one 10 mm move and watch the measured time drop toward the 0.12 s floor. The wrist camera and its bracket are part of the payload, not an accessory to it, and they rotate with every tracking increment.

Which termination type keeps tracking picks fast?

Blend consecutive tracking increments with a continuous (CNT) termination and reserve an exact-stop (FINE) termination for the pick and place points. FINE forces a full stop and a settling pause at every command, and a stream of short moves pays that pause every time.

Termination type is the third lever on the triangle: it decides whether each small move runs down to zero speed or hands its momentum to the next. Circular tracking sharpens the issue, because the motion is interpolated composite motion — position, encoder offset and your tool-frame offset resolved every control cycle — and interpolated servo motion plans differently from plain point moves, as why interpolated servo motion runs slower than point moves explains. The practical balance is the one your cell already found: moderate speed, blended increments. Keep FINE where the grip needs exact position and let everything in between blend.

Does a wrist-mounted camera slow the tracking loop?

The camera does not slow the move, it adds latency in front of it: capture, PC process, tool-frame offset, then move. At 300 mm/s of surface speed, every 100 ms of loop sends the part 30 mm further around the circle before the robot starts.

Shrink the loop at both ends. Expose briefly and strobe rather than lengthening exposure, keeping the strobe duty cycle matched to the light controller — the LED strobe duty cycle: matching lights and controllers guide gives the matching math. Take the conveyor encoder into the controller as the tracking reference, as the conveyor encoder sharing for multi-robot vision picking guide lays out, and place the sensor so its field of view leads the pick window — the conveyor tracking camera placement relative to the robot guide covers the geometry. For the sensor choice itself, the 2D or 3D camera for conveyor pick and place guide compares the options.

Then keep the compute inside the cell. The MV-VC5525-256G70-NN pairs PoE camera ports with eight built-in light channels and 32 GB of memory, so camera, strobe and vision process hang off one controller beside the robot instead of an office PC across the floor.

If the vision load is light, the MV-VC3301H-128G66 runs an Intel Core i3 with 8 GB of memory and four built-in light channels on the same pattern. Either way, mount the camera on a rigid bracket rather than an improvised plate: the camera stands category carries the standard bracket hardware, and the vision controllers category is where the rest of the compute line lives.

How do you find out where the cycle time goes?

Split robot-move time from wait time, then sweep the two variables that set it: distances of 1, 20 and 100 mm at a fixed speed expose the flat overhead floor, and speeds across the available range at the reference distance expose the fastest setting.

1. Time-stamp the vision result at publish and the move-complete signal at the controller; the gap is latency, the second window is the move itself.
2. Run the distance sweep at the lower speed setting. Where the time stops being flat, cruise has begun; below that distance, every move is a triangle.
3. Run the speed sweep at the reference distance and keep the measured minimum — expect it near the lower setting, not at the top of the range.
4. Log a full production shift before and after each fix, because single cycles hide tracking waits.

If the sweep looks right and picks still hesitate mid-cycle, the conveyor tracking pick hesitation: motion and timing checks guide walks the wait paths between vision and motion.

What should you change first?

Fix the payload schedule first, drop the speed target to the measured minimum for millimetre tracking moves, blend the increments with CNT termination and trim the vision loop last. Re-measure the same move after each change so every gain is attributable.

1. Payload schedule. Enter the real mass, center of gravity and inertia, camera included. Expect the largest single drop here, toward the 0.12 s triangle plus residual overhead.
2. Speed target. Keep the measured minimum from the sweep, typically well below the top of the range on millimetre moves.
3. Termination. Blend increments with CNT; keep FINE at the pick and place points only.
4. Vision loop. Short strobe, encoder reference, compute in the cell.
5. Acceleration class. Change it only after the four above: values below 100 soften acceleration and deceleration together, and values above the controller's standard buy time only where moves genuinely cruise, trading gearbox wear for it.

Done in that order, that same move lands near 0.15-0.25 s instead of the 0.46 s you started from — the 0.12 s triangle plus 30-100 ms of trimmed overhead. Treat that band as a model estimate and let your sweep set the number. If you want the capture-to-move hardware checked against your move list, send the cycle to us through the quote page; the rest of the conveyor-tracking library sits on the systems topic page.