After a crash, a board swap, or a “quick touch-up” on third shift, teams discover they cannot say which robot program was supposed to be running. The pendant shows something. The laptop folder shows three files with similar names. Production shows scrap that matches none of them cleanly.
Robot recommissioning checklists and TCP verification sheets assume you know which program you are restoring. This note is robot program backup and revision discipline—offline masters, naming, and restore proof. It is not energy-chain cable wear, not absolute-encoder battery loss, and not cycle-time waterfall analysis.
A workable scheme is deliberately dull:
- One master per cell and product family, stored off the pendant, with a revision ID in the filename and inside a program comment.
- Change control for path, speed, and I/O edits—who changed what, why, and which revision became active.
- Restore drill after controller events: load the master, verify checksum or byte compare where the OEM allows, run a dry-cycle gate before parts.
- Pendant is a runtime copy, not the archive. Treating it as the only copy is how Friday’s tweak becomes Monday’s mystery.
Sites that skip offline backups learn during the first dead controller. Sites that keep dated masters and a short restore procedure recover the cell instead of reconstructing motion from tribal memory. If you cannot name the revision on the floor right now, you do not have version control—you have folklore with a teach pendant.