A robotic cell is running slower than the plan promised, so someone proposes a new gripper, a re-teach of the path or a firmware update. Every one of these is a reasonable idea, and every one will be judged by whoever happens to be standing near the line the next day. To judge it properly, you need a documented picture of how the cell behaves right now. The procedure below walks through capturing that picture in a robotics operations setting, in the order the work is best done.

Step 1: Define the boundary of what you are measuring

Decide which cell, which product and which shift pattern the baseline covers, and put that scope in the first lines of your record. A robot that handles three part variants has three behaviours, and mixing them produces an average that describes none. Include the software and tooling versions in force today, since a later update will make them unrecoverable from memory.

Step 2: Pick a small number of observations in advance

Choose before you look at any data. Typical candidates for a robot cell are the time one full operation takes, the number of unplanned stops in a shift, the share of parts that need rework or rejection, and the waiting time caused by upstream or downstream equipment. Four is plenty. Selecting measures afterwards invites you to favour whichever one looks best.

Note, too, how each will be captured. A stopwatch reading and a controller log can disagree, and the later comparison must use the same source as the baseline.

Step 3: Confirm the instruments are trustworthy

Sensors and counters have quirks. Before relying on them, check a few readings against an independent observation, such as a person timing a cycle or counting parts by hand. The way sensing is wired into robots, covered in the explainer on how industrial robots incorporate sensors, affects what can be observed and how reliable it is. Record any known blind spots, for example a proximity sensor that misses glossy parts.

Step 4: Collect over a representative period

Gather data across several ordinary shifts, including the awkward ones: first start of the day, changeovers and the end-of-shift rush. Flag anything unusual, such as a maintenance visit or a material batch known to be difficult, so it is not mistaken for typical behaviour. Resist the urge to tidy the cell or retune anything during the period. You are watching, not fixing.

Step 5: Note the variation, not just the average

An average cycle time conceals how much it moves. Record the fastest and slowest typical cycles and how often stops cluster around particular times or part types. This spread is your noise floor. If a later change shifts the average by less than the cell already wobbles by itself, you cannot claim success.

Step 6: Capture the human side

Operators and technicians know things the logs do not. Ask what they dislike about the cell, which fault they see most and what workaround they have quietly adopted. Write the answers down in their words. In mixed fleets, such as those described in the overview of warehouse automation using guided vehicles, these informal observations often explain the numbers, and they provide a qualitative check once the change is made.

Step 7: Store the baseline where it will survive

Save the raw data and the summary in a shared location, with the date and the people involved. Raw logs matter because a surprising later result will make you want to inspect individual cycles, not a summary table.

A note on references from outside the plant

Careful measurement habits show up wherever stakes are high and planning is complicated. A directory like BestEyeHospitals, built to help international patients plan their eye-care journeys, steps visitors through country information and a structured enquiry, and a disclaimer on the site tells readers that its pages are informational and that details should be confirmed with providers directly. The moral for a robotics team is familiar: pin down what you already have before comparing any new proposal against it.

Step 8: Change one thing and keep everything else still

Now apply the new gripper, the revised path or the firmware update, but only one of them. If a re-teach and a firmware change land together and the cell improves, you will have a nicer line and no explanation. Keep material, shift pattern and operators as constant as practical for the comparison period.

Step 9: Repeat the same collection

Use the same boundary, the same observations, the same instruments and a similar span of shifts. Then compare the records side by side. Ask what moved by more than the earlier variation, what did not move, and what got worse. A faster cycle that raises rejects is a trade, not a win, and only a baseline lets you see it.

One practical tip for the whole sequence: assign a single person to own the record during collection. When three people each keep partial notes, gaps appear exactly where the interesting events happened, and reconciling them later is miserable. A named owner, a shared file and a short end-of-shift entry are enough to keep the picture complete.

Where this saves the most trouble

• Vendor claims. A promised improvement can be tested against your own recorded behaviour, not a brochure.
• Disputes between shifts. A shared record settles arguments about whether the cell has really degraded.
• Safety-relevant changes. Knowing normal stop patterns helps you notice when a modification changes them.

Teams that live by operating figures, as the article on the performance indicators factory managers watch in robotics suggests, still need a starting reference for each of them. Take nine steps’ worth of notes before the next upgrade, and the upgrade will have something honest to answer to.