Disaster Recovery Planning for a Cell

Inventory every controller in the cell

List every robot, PLC, and safety controller with model numbers and software versions. For each FANUC controller note the application tool and version shown on the utilities screen, since a restored image must match the software it came from. Keep this inventory as the first page of the plan.

Record each controller's memory-module sizes

During an image restore the boot monitor reports the current FROM and SRAM sizes, for example FROM 32Mb and SRAM 3Mb. Write these figures down for every controller, because an image only restores safely onto a controller with the same FROM and SRAM sizes.

Caution: The restore screen warns that restoring an image onto a controller with a different FROM or SRAM size can cause fatal damage to the controller. Treat memory-module size as a matching requirement, not a detail.

Capture an "all of above" backup for each robot

On the teach pendant press MENU, select 7 FILE, press F4 [BACKUP], then choose 8 All of above. This writes the system variables (SYSVARS.SV), servo parameters (SYSSERVO.SV), mastering data (SYSMAST.SV), macros (SYSMACRO.SV), frames (FRAMEVAR.VR and SYSFRAME.SV), registers, I/O configuration, robot setting files, and TP programs.

Capture a full controller image for each robot

The all-of-above backup leaves out the image, so add one. From the FILE menu in cold start, press F5 [UTIL], Set device, pick MC:, UD1:, or UT1:, then press F4 [BACKUP] and select Image backup on the second backup page. Confirm Cycle power, and the controller writes the FROM and SRAM image files (FROM00.IMG through SRAM02.IMG) on the next power-up and shows DONE.

Caution: During image backup do not turn off the power and do not remove the memory card or USB device. If the write is interrupted the image is incomplete and will not restore.

Follow the manual's recommended save order

The appendix defines an order for a controller in trouble: save the diagnostic log first (about one minute, before power off), then maintenance data (about three minutes), then an all-of-above backup (about one minute), then an image backup (about three minutes). Bake this sequence into the plan so an operator captures volatile diagnostic data before anything is powered down.

Caution: Save the diagnostic log only once, immediately after a problem. Saving it repeatedly for the same fault overwrites the data captured at the moment the fault occurred.

Document mastering method and reference position

For each robot record the mastering method in use and whether a reference position has been set and verified. This matters because after a battery or controller loss the SYSMAST.SV data may not be enough on its own, and a set reference position is what makes quick mastering possible during recovery.

Save network and I/O configuration explicitly

Record IP addresses, the I/O map, UOP and SOP assignments, and fieldbus settings in the plan itself, not just inside the backups. The I/O configuration (*.IO) and robot setting (*.DT) files ride along in the all-of-above backup, but a written copy lets you rebuild communications even if a backup is missing or unreadable.

Set up automatic backup so copies stay current

Press MENU, 7 FILE, F1 [TYPE], then Auto Backup. Automatic backup runs the all-of-above operation on a schedule of up to five times a day, on a rising DI, or at power-up on an interval that defaults to seven days. Set Automatic Backup to ENABLE and choose a device.

Initialize and size the automatic-backup device

The default device is the onboard backup area FRA:, which is already initialized and keeps its contents without a backup battery. A memory card must be initialized with F2 INIT_DEV before it will accept automatic backups. Size the card using (program size + 200 KB) times (number of versions + 1); the version count runs from 1 to 99 and defaults to 2.

Caution: The manual notes that if the automatic-backup device becomes faulty its data may be unreadable, so keep a second copy on separate media. Backups that live only on the controller do not survive a fire or a dead controller.

Copy backups off the controller and off-site

Move each robot's all-of-above backup and image off the controller onto a memory card or USB device, or push them to a TFTP server over Ethernet. Keep one full set somewhere that survives a local incident in the cell. Label every set with the robot name, date, and software version.

Caution: Use only English letters and numbers in backup folder names. Other characters can corrupt the image files when you later restore them.

Identify spare hardware and lead times

Note which spare controllers, drive amplifiers, motors, and batteries are on hand and the lead time for anything not in stock. Confirm any spare controller has FROM and SRAM sizes that match the image it would receive. A spare that cannot accept the image is not a usable spare.

Write the ordered recovery procedure

Document the exact sequence: replace hardware, restore the image or the all-of-above backup, remaster if needed, then verify. For a controller replacement, restoring the matching image rebuilds F-ROM and S-RAM in one step; for a software rebuild, use controlled start and F4 [RESTOR] with All of above, then cold start.

Include the controlled-start restore path

To restore all-of-above data, power on while holding PREV and NEXT, then select 3 Controlled start. On the file screen press F4 [RESTOR], choose All of above, and confirm the overwrite. When restoring individual system files the controller asks to convert for compatibility; normally select YES, then cold start.

Rehearse a restore before you need it

Restore a robot's image or backup onto a spare or bench controller and confirm it boots and reports the expected configuration. A plan that has never been exercised hides missing files, wrong media, and size mismatches. Record how long the rehearsal took so recovery estimates are real.

What can go wrong: the image will not restore to the replacement controller

You hold both F1 and F2 during power-up, select the device, and the boot monitor reports FROM and SRAM sizes that differ from the image. Stop there. Source a controller whose module sizes match the image, or rebuild that robot from the all-of-above backup through controlled start instead.

Caution: Do not force an image onto a mismatched controller to save time. The restore screen states this can cause fatal damage, and a bricked controller lengthens the outage.

What can go wrong: the robot loses position after a battery or controller loss

If the Pulsecoder backup battery goes flat or a cable is disconnected, a SRVO-062 BZAL alarm signals that absolute position data is gone, and after the next power cycle a SRVO-075 pulse-not-established condition appears. Correct the cause first by replacing the battery or repairing the cable, then remaster the affected axes. Lock out and tag out the power before replacing the battery or repairing the cable; remastering is a qualified-technician task.

Caution: Route remastering to a qualified technician and follow the mastering procedure. If a verified reference position was recorded in the plan, quick mastering can restore the robot without a full re-teach.

What can go wrong: the backup media is unreadable when you need it

A memory card can develop a file-system error that corrupts stored files and forces a reformat, which destroys anything still on it. This is why the plan keeps a second copy on separate media and off-site. Verify each set opens and lists its files during the periodic review.

Caution: Never rely on a single card or a single onboard area for a cell you cannot afford to lose. One faulty device should never be able to take out your only backup.

What can go wrong: an image backup reports failure

After a cycle-power image backup, the controller can display that the image backup failed and post an alarm to the log whose code carries the failure cause. Check available space, confirm the card or USB device is seated, and re-run the backup. Do not assume a failed image exists; verify the .IMG files are present before you rely on them.

Review and update the plan periodically

Revisit the plan after any change to programs, hardware, frames, or layout, and refresh the backups that go with it. Confirm the inventory, module sizes, and mastering notes still match the cell. An out-of-date recovery plan fails at the worst possible moment.