How to Time-Study a Robotic Cell and Calculate Cycle Time Correctly ART-025

First define what you mean by one cycle

Time-study errors often appear before the stopwatch starts. One project participant measures robot motion time, another measures the technological process, and a third measures the interval between two finished parts. All three numbers may be correct, but they describe different things.

For a production cell, cycle time is best tied to one repeatable system state. For example: from the moment the technological machine finishes one part to the same moment for the next part; or from the start of one machine cycle to the start of the next — if that event repeats consistently and matches the purpose of the measurement.

The key rule is that the start and end must describe the same state. Then the elapsed time naturally includes everything that actually delays the next repetition: part exchange, waiting for the process, a blocked output, operator work, or a missing workpiece.

Do not call only the sum of manipulator motions the cycle time. The robot may spend a large part of the real cycle waiting for the machine, while the machine may wait for the robot. For throughput, what matters is not the utilization of one mechanism but the calendar interval between repeatable outputs of the system.

Time study starts with events, not with the impression that “the robot stands still too long”

During observation, record not only duration but also what started, what ended, and which resource was occupied.

For each event, it is enough to capture:

• start time;
• end time;
• resource: robot, technological machine, operator, positioner, buffer, conveyor, or another element;
• short action name;
• whether the action blocks the start of the next cycle;
• whether it can actually run at the same time as another action;
• if there was waiting — what or whom the system was waiting for.

This form intentionally contains no “standard seconds.” Its purpose is to reconstruct the actual sequence of the specific cell.

If the controller or production system already records event logs and cycle times, compare those data with direct observation. ABB, for example, uses Cycle Time and Event Logs as separate views in its robotic analytics tools: one number shows the cycle trend, while the event log helps explain what actually happened inside it.

Observation should not require changing safety functions or entering a hazardous area. For time study, normal logs, system signals, video from an approved location, or external observation under the site's existing rules are sufficient.

Sequential time adds up; parallel time does not

The most important part of the model is correctly separating non-overlapping work from operations that can run at the same time.

If, after processing is complete, the robot must first remove the finished part, then install a new one, and only after that can the machine start, those actions are in a sequential chain. Their elapsed times add together.

But if the robot can pick the next workpiece from a buffer while the machine is processing, that preparation must not be added again on top of the entire machine cycle. It already happened inside the same calendar interval.

That is why, for a robotic cell, it is more useful to draw resource timelines than to write one formula that simply lists every operation. The cell clock is governed by the longest non-overlapping chain between two equivalent system states.

Overlap cannot be assumed merely because two operations are “theoretically independent.” It exists only when the actual architecture allows them to run simultaneously: resources do not conflict, the required zone is available, the buffer is not occupied, and the control logic does not make one action dependent on the other.

Fronius provides a clear production example of this type of overlap: in a two-station robotic welding cell, the next component can be loaded at the second station while the previous one is still being welded. This does not mean that all loading is “free” in time; it means that its contribution to the critical path depends on the cell architecture.

Illustrative example: why 6 + 24 + 9 does not necessarily equal the cycle

The numbers below are not robot norms and not recommended speeds. They are only an arithmetic example used to demonstrate overlap logic.

Assume that after one part is finished:

• the robot spends 6 s unloading the finished part and installing a new one;
• the technological machine then runs for 24 s;
• while the machine is running, the robot spends 9 s preparing the next workpiece in a separate available buffer.

If those 9 seconds genuinely fit entirely inside the 24 seconds of machine operation and the preparation is complete before the next exchange, they must not be added again.

The elapsed time from completion of one part to completion of the next in this illustrative scenario is:

`T_cycle = 6 s + 24 s = 30 s`

not `6 + 24 + 9 = 39 s`.

Now change only one condition. After the process finishes, the output position is occupied, and the cell cannot begin unloading for 5 s. That is now blocking waiting on the critical path:

`T_cycle = 5 s waiting + 6 s exchange + 24 s process = 35 s`

The numbers are intentionally invented. What matters is not the result of 30 or 35 seconds, but the audit method: every interval is visible on the timeline, and parallel time is not counted twice.

Waiting should be recorded as its own state with a cause

The statement “the robot stood still for 12 seconds” explains almost nothing. You need to know what it was waiting for and whether that wait increased the interval between good parts.

In practice, it is useful to separate at least these states:

This separation protects against two opposite mistakes. The first is treating every period of robot idle time as “inefficiency.” The second is excluding material or operator waiting from the calculation simply because the robot itself is technically ready to move.

ABB explicitly links integrated robotic machine tending with lower idle time in robot-machine interaction. For time study, the useful lesson is causal: identify who is delaying whom instead of looking only at the percentage of time the robot is moving.

Do not hide changeover inside an “average cycle”

The repeated time of one stable part and the transition between different jobs are different production phenomena.

If a gripper, fixture, program, position, or other configuration changes once per batch, it is useful to measure that separately:

• from the beginning of the stop of the previous job;
• until the new job can stably produce good parts.

You can then calculate two different metrics.

Stable repeated cycle time shows how the cell works within a repeating series.

Actual batch time shows the calendar from the start of changeover to the output of the last good part.

For short-batch planning, a derived metric can sometimes be useful:

`T_per_good_part_in_batch = T_actual_batch_time / N_good_parts`

This is not the “true robot cycle” and not an equipment characteristic. It is a planning metric for the specific batch that shows how strongly changeover and pauses affect a small quantity.

Do not spread one long changeover across all future products or introduce a universal reserve factor. Measure your own frequency and duration of transitions for the actual product mix first.

One clean showcase cycle does not describe production

Even in a well-tuned cell, consecutive cycles may differ. The reason may be different parts, buffer state, operator work, repositioning, conveyor waiting, or another permitted change in the system state.

After drawing the first timing diagram, observe a series of repetitions and keep not only the final number but also the cause of each deviation.

There is no need to collapse everything into one average immediately. First separate:

• stable repeated cycles;
• cycles with blocking waiting;
• cycles after changeover;
• cycles with manual intervention;
• cycles in another buffer or downstream state.

Only after this separation does an average become meaningful because you can see which states it mixes together.

The same logic applies to digital monitoring. ABB OptiFact, for example, shows Cycle Time trends and Event Logs separately; this is a useful reminder that one timing metric without event context does not explain why the cycle changed.

The cell boundary ends where the downstream operation stops blocking it

Agree in advance on what is being measured: the robot's internal cycle, the cycle of one technological machine, the complete robotic cell, or the throughput of a larger line.

If the robot places a part into a buffer and that buffer almost always has free space, a slower downstream operation may not change the cell's internal cycle — at least until the buffer fills.

But when there is nowhere to send the finished part, the downstream constraint enters the critical path. Then the correct statement is not “the robot became slower,” but “the cell is blocked by the next resource.”

This is especially important when comparing a demonstration cycle with the real production area. In a separate test, the output container may be empty, workpieces always ready, and the operator constantly nearby. Those conditions may change in production, and the time study should show them as separate states rather than hide them inside one coefficient.

Simulation and actual time study answer different questions

Offline simulation is useful before the cell is launched: it can compare trajectories, sequences, and design alternatives. Fronius Pathfinder, for example, explicitly includes cycle-time determination and robotic-welding sequence simulation.

But simulation time should not automatically be treated as production throughput. In the real cell there are material states, actual machine signals, waits, an operator, buffers, and downstream operations.

A strong validation therefore has two layers:

1. design timing model — what should run sequentially, what may overlap, and what dependencies are built into the architecture; 2. actual time study — whether that overlap really happens on the production system and which additional blocking states occur in operation.

A difference between them does not by itself mean that the integrator or equipment is at fault. First find the specific interval that is missing from the design model or that became longer in production because of a different condition.

A practical analysis sequence

A useful model does not require a complex analytics system. A straightforward sequence is enough:

1. Define the repeatable start/end event of the cycle. 2. Draw separate time lanes for the robot, main process, operator, and critical buffers. 3. Record the actual start and end of each action. 4. Mark which action blocks the next repetition. 5. Mark proven overlap separately. 6. Give every wait a cause. 7. Keep changeover outside the stable repeated cycle. 8. Check several states — normal flow, another part/batch, full or empty buffer, operator involvement — but only the states that actually occur in your production. 9. Compare improvements not by “how much faster the robot moves,” but by how much the longest non-overlapping chain is shortened or a specific blocking wait disappears.

If you need a simple factual check without reconstructing every micro-action, use the boundary events themselves:

`T_cycle,k = t_start,k+1 − t_start,k`

where `t_start` is the same repeatable event in adjacent cycles.

For throughput over an actual observation window:

`Q = N_good_parts / T_observation`

Do not substitute one metric for the other. `T_cycle` helps explain the mechanics of one repetition, while `Q` shows actual output over calendar time that may already include waiting, blocking, and changeovers depending on the selected observation window.

What data to bring to a robotization discussion

You do not need an “ideal OEE” for a useful engineering conversation. The following are much more informative:

• one or two timing diagrams of the real cycle;
• a list of recurring blocking waits;
• actual changeovers between the main part families;
• material supply and unloading data;
• the operator's role;
• buffer capacity and state;
• downstream-operation requirements;
• several representative parts or batches, not only the most convenient demonstration cycle.