Do CNC Machines Save Every G-Code Program They Run?

• 1
  What Happens Inside the Control When a Program Runs
• 2
  Three Storage Tiers on a Typical Machine
• 3
  How Programs Actually Get Lost
• 4
  Building an Archive That Survives a Crash
• 5
  Why This Matters on Tight-Tolerance Work
• 6
  Step by Step: Protect a Program Before You Run It
• 7
  Where a Program Lives and What Threatens It

A CNC control is not a file server. When you load a program from a USB stick, a network share or the machine's own memory, the control copies it into working memory and executes it line by line. That working copy is the one the servo loop and the look-ahead buffer actually see. On a Fanuc-style control this is often called the active program. On a Siemens or Heidenhain control the wording differs, but the behavior is the same.

The important part: execution and storage are separate functions. The control reads blocks, interpolates motion and drives the axes. Whether the same blocks are written to non-volatile storage afterwards is a configuration choice, not a side effect of running the job. ISO 6983 defines the code format, not an obligation to archive it. That is why two machines from the same builder can behave differently depending on how the integrator set them up.

Volatile memory needs continuous power. A power cut, an e-stop that drops the control supply, or a firmware reset clears the working copy. If nobody saved it before that moment, the program is gone. On many shop-floor machines this is exactly what happens, and it is the root of the frustration behind the question: do CNC machines save the program I just ran?

• 1
  Active programThe copy in RAM that the control executes right now.
• 2
  Machine memoryNon-volatile space for programs the operator chose to keep.
• 3
  External mediaUSB, CF card, network share or DNC host, outside the control.

Tier one is RAM. It is fast and small, sized in hundreds of kilobytes on older controls and a few megabytes on newer ones. It holds the active program plus offsets, parameters and the look-ahead buffer. Nothing in RAM survives a supply loss. If your machine powers down mid-cycle and the program disappears, you were working from tier one only.

Tier two is the control's own non-volatile memory, usually flash or battery-backed SRAM. Programs here survive a power cycle. Capacity is limited and awkward: many older controls hold a fixed number of programs, or a fixed number of characters, and refuse new files once full. Operators hit this as a memory alarm partway through a long cycle. The fix is deleting old jobs, which is also how programs get lost by accident.

Tier three is outside the control: USB, memory card, network share, or a DNC host that drip-feeds the program. Tier three has effectively unlimited capacity and is easy to back up. It is also the only tier that survives a control board failure, a battery replacement gone wrong, or a machine being moved. Treat tier three as the master copy and the other tiers as working space.

A fourth pattern exists on newer machines: the control runs an embedded operating system and stores programs on internal flash like a PC. This looks convenient, but the same rules apply. Somebody still has to decide what gets archived, and a wiped flash is a wiped flash.

• 1
  RAMActive execution only. Cleared by power loss or the next load.
• 2
  Control memorySurvives power cycles. Small, fixed size, easy to overwrite.
• 3
  External or DNCThe master archive. Back it up off the machine.

The most common loss is not a crash. It is a second program loaded over the first. The operator finishes a job, loads the next file into the same active slot, and the previous program is gone before anyone thinks to save it. On controls with a single active slot, this happens every shift.

The second cause is a power event. A shop-wide outage, a tripped breaker, or a control battery going flat all drop volatile memory. Battery-backed SRAM is a slow trap: the battery lasts years, then fails, and the programs go with it. If nobody recorded when the battery was last changed, the loss looks sudden.

The third cause is housekeeping. Memory full means deleting files. Operators delete the oldest or the ones they think were finished, and a program that was still needed for a repeat order disappears. Naming practice makes this worse. Files called O0001, O0002 and TEST carry no information about part number, revision or fixture.

The fourth cause is a control or drive failure. When a board is replaced, internal memory is often cleared or restored from a factory image. Any program that lived only on that board is gone. External archives turn this from a lost program into a re-download.

• 1
  Overwrite on next loadSingle active slot, no automatic save.
• 2
  Power lossRAM clears; battery-backed memory clears when the cell dies.
• 3
  Cleanup by handDeleting to free space removes the wrong files.
• 4
  Board replacementInternal memory may be wiped during service.

Save the verified program, not the first draft. Prove the job out, adjust speeds and lead-ins on the floor, then write the corrected file back to the archive and stamp it with the revision. The file that gets stored should be the one that made good parts. Any change made at the control after proving must go back to the master copy or the two will drift apart.

Use a naming convention that carries the part number, revision letter and operation. Something like 4471-B-OP20 is readable to anyone in the shop and sorts correctly on a PC. Add the machine family if the same part runs on different controls, because a program proven on one control may need post-processor changes for another.

Keep the master off the machine. A network share or a versioned folder on a shop server is better than a USB stick that lives in the operator's drawer. Back that share up on a schedule. If the only copy of a 4,000 mm long program is on a memory card taped inside the cabinet, a single failure costs you the setup time again.

Automate what you can. DNC systems and file-management tools can push programs to machines and pull the as-run file back, which removes the human step that gets skipped on a busy shift. Whatever the method, the test is simple: can you rebuild the program from the archive after the control is wiped? If the answer is no, the archive is not finished.

• 1
  Save after provingArchive the corrected file, not the CAM output.
• 2
  Name for humansPart number, revision and operation in the filename.
• 3
  Keep it off the machineServer or versioned share, backed up on a schedule.
• 4
  Rehearse recoveryConfirm one program can be restored end to end.

On a part held to ±0.005 mm, the program is part of the process record. If a revision change altered a cutter compensation value or a feed rate, and that change was never written back to the archive, the next run starts from a different place. The part may still pass inspection, or it may not, and nobody can tell which file produced the good parts.

This links directly to inspection and traceability. When a customer asks which program revision ran on a lot, an archive with revision letters can answer in minutes. A machine memory full of O0001 files cannot. For regulated work in medical devices or automotive, that gap is a documentation problem, not just a convenience problem.

Storage also sets a practical limit on program size. A long 3D contouring path for a large part can exceed the control's memory, which pushes the job toward drip-feeding over DNC. Drip-feeding works, but it depends on a stable link. If the cable or the host hiccups mid-cycle, the machine stops and the surface may be marked. Know your program size before you quote the job.

None of this changes the machine's accuracy. It changes whether you can repeat the result. The controls, the tooling and the fixtures are the same; the archive is what makes the next run match the last one.

• 1
  Process recordThe archived revision documents what actually ran.
• 2
  TraceabilityRevision letters answer customer questions fast.
• 3
  Program sizeLarge paths may need drip-feeding over a stable link.