Cycle time vs real-world throughput: why brochure claims are misleading
Vendors publish cycle times measured at maximum speed with no tooling and ideal paths. Here is what the number looks like in production.
A packaging line evaluator approved a pick-and-place robot based on a vendor demonstration: 1,800 picks per hour, 0.5-second cycle time per pick, clean and fast. Three months into production, the line was running 1,050 picks per hour. Not because of breakdowns — the robot ran reliably. The shortfall came from gripper dwell time, camera settle time, downstream conveyor indexing, and the 12-minute warmup the programmer built in to prevent missed picks during the arm's cold-start thermal ramp.
Nobody had modeled any of those factors at evaluation time. The vendor's 1,800-picks number was real, measured under real conditions — just not those conditions.
This gap between published cycle time and production throughput is systematic, it is measurable, and it is avoidable if you know what to look for.
What vendors measure when they publish cycle time
Robot manufacturers measure cycle time on standardized test paths to produce a comparable, repeatable number. The common reference is a "pick-and-place cycle" that the International Federation of Robotics (IFR) and most major vendors use: a horizontal move of a defined distance (typically 300 mm or 500 mm), a vertical drop of 25 mm at each end, at rated maximum speed, with no payload or with a minimal test mass. The robot's controller logs the time from motion start to return to start position.
This is an ideal-path measurement. It tells you: given this specific geometry, at maximum velocity, with no EOAT mass, how fast does this arm move?
What it does not measure:
- Your actual path geometry, which may include longer moves, tighter radii, or paths that force the arm through unfavorable joint configurations
- Your EOAT mass, which adds inertia and forces the controller to reduce acceleration limits
- Your process timing: gripper close/open time, vacuum build/break time, vision system acquire-and-confirm time, sensor handshake latency
- Downstream system timing: conveyor indexing, fixture advance, upstream part presentation delays
- Controller-specific motion behavior: CNT (Continuous Turn) or zone settings that trade path precision for speed, versus fine-stop modes that sacrifice speed for precision
- Warmup drift: some robots reduce speed automatically during the first operational period while thermal equilibrium builds
Each of these factors adds time. Together, they are the difference between 0.5 seconds and 3.4 seconds.
The four components of a real cycle time
When engineering a production cycle, model these four elements separately and add them together.
1. Robot motion time
This is the closest to the vendor's published number, but still not identical. Real motion time reflects:
- Actual path length and geometry: longer, more complex moves take longer
- Velocity and acceleration limits at your payload: these scale nonlinearly — doubling the payload does not halve the speed, but the controller does reduce both acceleration ramp rates and peak velocity at higher payloads
- Joint limits and singularity avoidance: the path planner may insert longer routes to avoid singularities or joint limits, adding time invisibly
The best tool here is the vendor's offline programming (OLP) software. Import your actual path, enter your actual payload, and let the simulator calculate the motion time. This takes 2–4 hours of an application engineer's time and is worth every minute.
2. Process dwell time
The time the robot spends stationary waiting for the process. This includes:
- Gripper timing: pneumatic grippers typically take 100–300 ms to fully open or close; servo grippers are faster but still measurable
- Vacuum build and break: vacuum suction cups require 100–400 ms to achieve seal; release requires break-blow time
- Vision system acquisition: if the robot must wait for a camera to acquire, process, and confirm a position, add 100–500 ms minimum depending on hardware and lighting
- Force/torque sensor confirmation: assembly applications may hold position while an F/T sensor confirms a seating force is achieved
- Weld or dispensing dwell: process robots hold position for the full application time
For a pick-and-place cycle, process dwell alone often adds 400–800 ms per cycle — 80–160% of the robot's pure motion time for short-range cycles.
3. System integration latency
The time the robot spends waiting for upstream and downstream equipment:
- Part presentation: the time between one part being removed and the next being positioned and stable
- Fixture or pallet advance: the indexing time for conveyors, rotary tables, or pallet changers
- Signal handshake: the I/O or fieldbus round-trip time between the robot controller and the line PLC. On older DeviceNet or EtherNet/IP setups, this can be 10–50 ms per handshake; on modern ProfiNET or EtherCAT, under 1 ms
- Human interaction: if an operator loads fixtures, the robot waits for a load-complete signal; cycle time now includes human variability
System integration latency is the hardest component to estimate before the cell is built, which is why simulation with actual PLC timing data matters.
4. Availability and planned downtime
A robot that runs 7.2 seconds per cycle but requires a 20-minute gripper change twice per shift, plus a 15-minute TCP calibration check every morning, does not run 7.2 seconds per cycle over an 8-hour shift.
Overall Equipment Effectiveness (OEE) is the standard framework for capturing this. The relevant components:
OEE = Availability × Performance × Quality
- Availability: actual uptime divided by planned production time. A robot with 97% availability runs 19.6 hours of a 20-hour day.
- Performance: actual output rate divided by ideal output rate. If the robot theoretically handles 400 units per hour but averages 310 due to minor stops, Performance = 77.5%.
- Quality: good parts divided by total parts. Relevant when the robot operation affects quality, less so for pure material handling.
World-class OEE in manufacturing is approximately 85%. For new robotic installations in the first 6–12 months, 65–75% is more realistic as teams work out integration issues, develop maintenance procedures, and tune motion parameters.
The practical calculation:
Published cycle time × performance factor × availability = realistic cycle time
A vendor-published 2-second cycle time, with 80% performance factor and 95% availability, produces an effective cycle time of:
2 s ÷ 0.80 ÷ 0.95 = 2.63 seconds effective cycle time
At 3,600 seconds per hour, that is 1,369 good cycles per hour versus the 1,800 the nameplate implies. The 24% gap compounds to 150 fewer parts per shift.
How to validate cycle time claims before you buy
Run an offline programming simulation. Every major vendor (FANUC, KUKA, ABB, UR, Yaskawa) offers OLP software, often free for evaluations. Import your cell layout, program your actual paths, set your actual payload, and read the simulated cycle time. The simulation will not capture process dwell or integration latency, but it will tell you if the robot motion time is anywhere near the vendor's published number at your specific geometry.
Ask for a reference site with your specific application. Not a generic pick-and-place site — a site doing approximately what you need to do, at approximately your throughput target. Ask that site's engineer what their actual OEE is and what the biggest cycle time contributors turned out to be. This is the most honest data you will find.
Time the vendor's demo, including all dwell and handshake time. Vendor demos are optimized, but they will include a gripper, a part, and a pickup/place cycle. Time it with a stopwatch from the moment the robot receives its pick signal to the moment the robot signals placement complete. That number includes at least some of the process dwell that the pure motion time omits.
Ask for the cycle time at your EOAT weight. If your gripper weighs 3 kg and the vendor's demo runs a 0.5 kg test mass, ask for the demo to be repeated at 3 kg or for a simulation result at that payload. Some vendors will run this in 20 minutes. If they won't, that is informative.
Build a cycle time model in a spreadsheet. It does not need to be sophisticated. List motion time, gripper time, vision time, conveyor index time, and estimate each based on your knowledge of similar systems. Apply a 0.80 performance factor and a 0.93 availability factor to the total. If the resulting throughput does not meet your takt time requirement, the robot is undersized or the cell design needs rework — before you commit.
Takt time: the number cycle time has to beat
Takt time is the maximum allowable cycle time to meet production demand. The formula:
Takt time = Available production time ÷ Required units
If you need to ship 4,000 units per 8-hour shift, and your planned maintenance accounts for 30 minutes of that shift:
Takt time = (8 × 3,600 – 1,800) s ÷ 4,000 = 6.75 seconds per unit
Your effective cycle time, after all the factors above, must be below 6.75 seconds. A robot whose datasheet says 3.5 seconds sounds like it has comfortable margin. If your process dwell, integration latency, and OEE reduction bring the effective cycle time to 6.2 seconds, you have 0.55 seconds of margin. That is not comfortable — it is fragile.
Engineers who have been burned by cycle time overestimates routinely target 80% of takt time as the design cycle time for the robot. That is, if takt = 6.75 seconds, design for a cell that can run 5.4 seconds effective cycle time under normal conditions. The remaining 1.35 seconds absorbs minor stop accumulation without throughput falling below the demand line.
The most common modeling mistakes
Using nameplate cycle time as the simulation input. The nameplate is not a simulation parameter; it is a marketing floor. Use OLP software or the vendor's application engineering team.
Omitting EOAT in the cycle time model. EOAT is part of the system. Adding it after cycle time validation is complete routinely breaks the model.
Planning for 100% OEE in the first year. No new automated cell reaches 85% OEE in the first 30 days. Plan for 65–75%, with an improvement plan and a 6-month horizon to reach target.
Ignoring warm-up requirements. Some robots, especially high-precision arms for small-part assembly, require programmed warm-up cycles before production tolerances are achievable. If this is not in the sequence, it will be discovered in production.
Assuming process dwell is fixed. Pneumatic grippers grip faster when supply pressure is higher and when temperature is consistent. If your shop floor has variable air pressure or your robot is near a large HVAC system, build variation into your dwell time model.
The bottom line
The cycle time on the datasheet is a lower bound measured under conditions that do not exist on your floor. Closing the gap between that number and your actual throughput requires modeling four real factors — robot motion, process dwell, integration latency, and OEE — with real inputs. This is an engineering exercise, not a negotiation. Vendors who tell you "just use the datasheet number with a 10% safety factor" have not done the analysis. Do it yourself.
Next in this series: Safety certifications you can't fake — ISO 10218, ISO/TS 15066, ANSI/RIA
