Robot Cycle Time & Throughput: The Parts-Per-Hour Math the Datasheet Skips

A robot’s spec sheet says its fastest joint turns at 750 degrees per second, or its tool moves at up to 11,000 millimetres per second. Neither number is your throughput. The number you actually need to plan a cell, parts per hour, comes from a cycle time, and cycle time is not “distance divided by top speed.” It is three time budgets stacked together: how long the robot waits to decide it can move, how long the move itself actually takes once acceleration and settling are counted, and how long it waits afterward for a gripper or a sensor. The formula is short. Getting the three pieces right is where the estimate lives or dies.

PPH = 3600 / T_cycle, where T_cycle = T_decision + T_motion + T_idle. Apply an OEE (Overall Equipment Effectiveness) factor on top, because no cell runs at its theoretical rate for a full shift, and you have the real number a datasheet never gives you directly.

Why the datasheet speed spec doesn’t answer the throughput question

Across the 273 robots in the Industrial Robotics Hub database, 135 publish a maximum axis speed figure and only 2 publish an actual cycle time. That gap is not an oversight. Peak axis speed is a single-joint number measured under a specific test condition; a real pick-and-place cycle involves multiple joints moving and stopping together over a short stroke, so the arm rarely reaches, let alone holds, its rated peak.

The two robots in our database that do publish a cycle time make the point directly. The Omron i4-650 SCARA is rated at a peak axis speed nowhere close to the fastest in its own class, yet its published cycle time for the industry-standard 25/305/25 mm pick-place move is 0.38 seconds - a number you cannot derive from the axis-speed spec alone, because it already bakes in acceleration, deceleration, and settling over that specific short stroke. That single figure is worth more for throughput planning than a peak-speed number ten times larger, because it is a real cycle, not a theoretical ceiling.

Run that 0.38-second cycle through the formula: 3600 / 0.38 = 9,474 theoretical parts per hour. Apply an 88% OEE, a reasonable mid-point assumption for a running cell, and the real number drops to 8,337 parts per hour. That 12% haircut is not a rounding error; it is planned tooling changeovers, the odd missed pick needing a retry, and minor stoppages that any real shift accumulates, and it applies before a single hardware upgrade would help.

The three time budgets, and why motion is not just “distance over speed”

Decision time. The gap between “a part is present” and “the robot starts moving.” A vision system confirming a part’s position, a photoeye triggering a pick, or a PLC handshake releasing motion typically costs 50-150 milliseconds. It shows up nowhere on a robot’s own spec sheet, because it depends on the vision or sensor system bolted around the arm, not the arm itself.

Motion time. The dominant piece of most cycles, and the one people wrongly assume equals stroke length divided by top speed. A real move accelerates, may briefly cruise if the stroke is long enough to reach peak speed at all, decelerates, and then settles for a moment so the payload stops oscillating before a gripper releases. Over the short strokes typical of picking, 100-400 mm, a robot often never reaches its rated peak speed before it has to start slowing down again, which is exactly why our SCARA vs Delta vs 6-Axis analysis found peak TCP speed and real picks-per-minute rank differently across formats. Payload inertia matters here too: a heavier part or a longer gripper moment-arm slows the achievable acceleration regardless of what the joint’s peak speed spec claims.

Idle time. The dead time after the move: a gripper actuating, a vacuum cup releasing, a part settling into a nest, or a conveyor indexing to the next position. Commonly another 100-300 milliseconds, and, like decision time, invisible on the robot’s own datasheet because it belongs to the end-of-arm tooling and the fixture, not the arm.

Add the three, and you get a cycle time you can actually defend, not one guessed from a peak-speed spec.

Peak axis speed by robot type, and why it’s context, not a throughput number

For orientation, here is the median peak axis speed by robot type across the 135 robots in our database that publish one. Read this as background on what each format’s fastest joint is theoretically capable of, not as a parts-per-hour prediction. A SCARA’s high number reflects a rigid planar geometry built for short, fast strokes; a cobot’s low number is very often a safety ceiling, not a mechanical limit.

Median of each robot’s fastest single joint, by type. Source: Industrial Robotics Hub database, 135/273 robots publishing performance.maxSpeedDegS. Delta’s n=2 is a small sample. This is a peak-capability figure, not a picks-per-hour estimate; see the three-budget breakdown above for why.

The cobot median sits nearly 9x below the delta and SCARA figures, and that gap is mostly regulatory, not mechanical: a power-and-force-limited cobot is deliberately governed to a safe speed under ISO/TS 15066 when working near a person, which is why cobot throughput realistically tops out around 20-40 operations per minute for typical paths, well short of what the same arm could do fenced. If a job needs a genuinely high parts-per-hour number, that constraint alone often rules the format out before cycle-time math even starts.

Worked example: reverse-engineering a cell from a throughput target

Most buyers start from the other direction: a line needs 600 parts per hour, and the question is what cycle time and what robot format can deliver it. Run the formula backward.

Step 1: theoretical cycle time budget. 3600 seconds / 600 parts = 6.0 seconds per part, theoretical.

Step 2: apply OEE. At a conservative 85% OEE for a new cell, the robot must actually complete its cycle in 6.0 x 0.85 = 5.1 seconds, not the full 6.0. At a more mature 90% OEE, that tightens slightly to 5.4 seconds. Either way, the real budget is meaningfully shorter than the naive theoretical number, which is the single most common planning mistake: speccing a robot exactly to the theoretical cycle time with no OEE buffer means any stoppage breaks the line’s rate for the rest of the shift.

Step 3: allocate the budget across the three pieces. A 5.1-second budget with, say, 100 ms decision time and 200 ms idle time leaves roughly 4.8 seconds for motion, comfortably inside reach for almost any format on a short stroke. But tighten the target to 60 parts per minute (3,600 per hour) and the same 85% OEE math leaves only 1.0 x 0.85 = 0.85 seconds per part total, and now decision and idle overhead alone (0.3-0.4 s combined) can eat nearly half the budget, which is exactly the regime where format choice stops being a preference and becomes the deciding factor.

Step 4: match the budget to a format, not a peak-speed number. A budget under roughly 1 second per part points toward SCARA or delta, the formats built around short-stroke acceleration rather than long-reach coverage. A budget of several seconds per part is comfortably inside articulated or cobot territory, and a cobot becomes viable specifically because it no longer needs to fight its own speed ceiling to hit the number. Our Cycle Time & Format Estimator runs this same OEE-adjusted math against your own throughput target, part weight, and shift pattern, and returns the format that clears it.

What this means for spec’ing a cell

Two disciplines fall out of the math. First, never accept a cycle-time number that hasn’t had an OEE haircut applied; a cell speced to the theoretical rate has zero margin for the stoppages every real shift has. Second, treat a robot’s peak axis-speed or TCP-speed spec as a ceiling on the motion piece of the cycle, not an estimate of the cycle itself, because decision time and idle time are set by the vision system, the gripper, and the fixture around the arm, not by the robot’s own datasheet. A palletizing-specific version of this math, where the moving mass and stroke pattern are different again, is a natural next companion to this piece; until then, the Factory Layout Planner and ROI Calculator round out the planning side of the same decision.

Sources: RoboDK, “Understanding Robot Cycle Time”; Standard Bots, “How to Reduce Robot Cycle Time”; Automation Calculators, robot cycle-time reference.