Symptom: a robot that placed parts accurately for months starts missing by a few millimetres. The team checks the gripper, the camera and the conveyor, and finds nothing wrong. Somebody remembers that the controller program was “tidied” a couple of weeks ago, but nobody knows what the tidy-up touched. This is the classic case for a version history for robot programs and settings, and this article walks through the diagnosis and the fix in the plain order a floor engineer would use.
The diagnosis: the working state was overwritten
Robot cells accumulate changes from many hands: a technician adjusts a waypoint, an integrator updates a speed limit, a vendor patch changes controller behaviour, and a night shift tweaks a gripper timing to clear a jam. Each change is reasonable alone. When they are all saved over the same program file, the cell has no memory of its own good state.
Three kinds of information go missing in these cases:
- The program itself: waypoints, speeds, logic and tool offsets.
- The configuration around it: safety zones, calibration values, network and fieldbus settings.
- The reasons: why each value was changed, and by whom.
Without the first two, you cannot go back. Without the third, you cannot learn.
The fix: dated revisions with a one-line reason
The remedy is dull and effective. Before any change to a program or setting, back up the current state and label it with the date and cell name. After the change, write one sentence: “raised pick speed on station three to clear a backlog; watch placement accuracy on small parts”. Store the backup and the sentence together, in a place every shift can reach.
Do this for calibration data too. Tool-centre-point values and camera calibrations are easy to overwrite and hard to rebuild, and they are often the real cause when accuracy drifts.
Reading the trail when something goes wrong
Back to the robot missing by a few millimetres. With a trail, the engineer lists the changes in the two weeks before the first bad part: a speed change on Tuesday, a controller patch on Thursday, a recalibration on the following Monday. She restores the program from before Tuesday on a test cell and runs it. Placement is fine. She applies the speed change alone and accuracy drops slightly. She has found the culprit in an hour rather than a week, and she knows exactly what to change next.
The method is simple bisection: step backward through the dated versions until the symptom disappears, then forward one change at a time until it returns.
Sensors and settings deserve the same care
Robots are only as accurate as their sensing. If a sensor mount or its configuration changes, behaviour changes with it. Our overview of the way sensing hardware is wired into industrial robots shows how many parameters sit between a reading and a decision, and every one of them is a candidate for a dated entry. A threshold nudged to cut false alarms is exactly the sort of change you will want to find later.
Mobile fleets add a twist
Warehouse vehicles bring extra moving parts: maps, route rules, traffic priorities and charging schedules. A revised map can quietly change the behaviour of every vehicle at once. Teams running such fleets, as described in our overview of automated guided vehicle warehouses, benefit from versioning maps and route settings as carefully as software, with a note on what the change was meant to improve and a clear way to return to the previous map during a shift.
Rolling back safely
Restoring an earlier program on a live robot is a physical act, not just a file operation, so follow your site’s safety procedures: stop the cell, confirm the restored version in a safe mode, check key positions slowly and only then resume. Record the rollback as its own dated entry with the reason. Never delete the version you rolled back from; it is evidence for the investigation and a warning for the future.
Handovers between shifts
Many robot faults start at a shift change. The day crew adjusts something, the night crew does not hear about it, and an unexplained difference appears at three in the morning. A shared trail removes the dependency on conversation. Each crew reads the latest entries at the start of the shift, and each writes theirs before leaving. It adds minutes to the handover and takes hours out of fault-finding.
It also helps when outside specialists visit. A vendor engineer who can read the last month of dated entries arrives already informed, and spends the call fixing the problem instead of reconstructing the history of the cell from operators’ recollections.
What to keep and for how long
- Every version that ran in production, until the cell is decommissioned.
- Every calibration set, with the date and the person who made it.
- Patch and firmware change notes, with what behaved differently afterwards.
- Scratch experiments only until their lessons are written down.
A note on cost
None of this needs new equipment. A shared folder, a naming rule and a habit of writing one sentence are enough to start. The expensive part of robot downtime is the hours spent not knowing what changed, and that is the cost a plain trail removes. Even a modest cell, stopped for an afternoon over an unexplained shift in behaviour, loses more output than a whole year of note-writing takes in effort.
Where reusable wording fits
Operations teams also reuse text: shift handover prompts, inspection questions and incident write-up outlines. Some keep reusable prompt instructions on Promptosia, where they can save, version and share them, and the same rule applies there as to a robot program: keep the earlier forms.
Getting started on the floor
- Pick the one cell that causes the most calls to your phone.
- Back up its program, settings and calibrations today and label the set with the date.
- Agree that no change is saved without a one-line reason.
- Run a rollback drill on a test cell so the process is familiar.
- Review the trail after a month and extend it to the next cell.
The robot that started missing by a few millimetres did not need a new gripper or a new camera. It needed a record of what had changed. Give your cells that record, and the next mysterious symptom becomes a short list of dated suspects instead of a week of guessing.
