CNC Breakpoint Recovery and Resume Machining: How to Pick Up Exactly Where You Left Off
Every CNC operator has been there. The program stops mid-cut. Maybe the tool broke. Maybe the power flickered. Maybe the operator hit the feed hold by accident. The part is half-finished, the tool is in the middle of nowhere, and you have no idea where the program left off.
Without breakpoint recovery, that half-finished part becomes scrap. You have to start over from the beginning, waste material, waste time, and lose money. With breakpoint recovery, you pick up the program exactly where it stopped, finish the cut, and move on.
This is not a luxury feature. It is a necessity on any production floor where downtime costs real money. The question is not whether you should use it. The question is how to set it up so it actually works when you need it.
What Breakpoint Recovery Actually Does
The Core Concept: Saving State and Resuming Later
When a program stops unexpectedly, the controller loses track of where it was. The next block to execute is gone. The current position is ambiguous. The modal states might have changed. Breakpoint recovery solves this by saving the complete machine state at the moment the program stopped, then restoring that state when you restart.
The saved state includes the current tool position, the active work offset, the spindle speed, the feed rate, the modal G-codes, and the next block number. When you resume, the controller loads all of this back and continues from the exact same line it was executing before the stop.
This sounds simple. But getting it to work reliably requires setting up the right conditions before the program ever runs.
Why Most Shops Fail at Breakpoint Recovery
The reason breakpoint recovery fails in most shops is not the technology. It is the setup. Operators write programs without breakpoint markers. They do not save the state before stopping. They restart the program from the beginning instead of from the breakpoint. The feature exists on the controller, but nobody uses it correctly.
A breakpoint recovery that is not configured properly is worse than no recovery at all. It gives you a false sense of security. You think you can resume from anywhere, but when you try, the tool crashes into the part because the work offset was not saved or the modal state was wrong.
How to Set Up Breakpoint Recovery Before You Run
Using M00 and M01 as Breakpoint Markers
The simplest way to enable breakpoint recovery is to place M00 or M01 in your program at key locations. M00 is a program stop. The machine halts, the spindle stops, and the coolant turns off. M01 is a conditional stop. It only stops if the operator has enabled the optional stop switch on the controller.
Place M00 after every major operation. After roughing a pocket, put M00. After drilling a row of holes, put M00. After finishing a contour, put M00. These markers give you defined recovery points. If the program stops anywhere between markers, you resume from the last marker, not from the exact line where it stopped.
The spacing between markers matters. If you put M00 every fifty lines, a crash at line forty-nine means you lose forty-nine lines of work. If you put M00 every five lines, you waste time stopping too often. Find a balance that works for your part complexity. For most milling jobs, a marker every ten to fifteen lines is a good starting point.
Saving the Program State With M30 and Custom Macros
Some controllers let you save the program state to memory using a custom macro or a special M-code. When the program stops, the macro writes the current position, the active offsets, and the modal states to a set of variables or to the controller memory. When you restart, another macro reads those values back and restores them.
This method is more reliable than relying on M00 alone because it captures the exact state, not just the last marker position. The downside is that it requires writing macros, which most shops avoid. But for high-value parts where every minute of downtime costs money, the macro approach is worth the effort.
On Fanuc controllers, you can use system variables to capture the current position and offsets at the breakpoint, then restore them on resume. On Siemens, you can use R parameters to store and recall the state. The syntax differs, but the logic is the same: save everything before you stop, restore everything when you start again.
Resuming After a Tool Break or Crash
What to Do When the Program Stops Mid-Cut
When the program stops unexpectedly, do not just hit cycle start. That will resume from the beginning of the program, not from where it stopped. You will replay every move up to the crash point, which means the tool will retrace its path and potentially crash again.
Instead, find the last block that executed successfully. On most controllers, you can scroll through the program history to see which block was running when the alarm triggered. Note the block number. Jog the tool to a safe position above the part. Then restart the program from that block number using the block skip function or by editing the program to start at that line.
If your controller supports block search, use it. Enter the last known good block number and start from there. The controller will skip everything before that block and resume at the correct position. This is the fastest way to recover from a mid-program stop.
Repositioning the Tool Before Resuming
After a crash, the tool is not where the program expects it to be. The program thinks the tool is at the last executed position, but the tool is actually sitting in the middle of the crash site. If you resume without repositioning, the first move after the breakpoint will drive the tool from its actual position to the expected position, which could be a rapid move through material.
Before resuming, jog the tool to the last known good position. Use the DRO to confirm the coordinates match what the program expects. If they do not match, adjust the work offset or the tool position until they do. Then resume.
This step takes two minutes and prevents a second crash. Skipping it to save time is the fastest way to turn a minor stop into a major disaster.
Resuming After a Power Loss or Emergency Stop
What Happens to the Program State When Power Drops
A power loss is the worst-case scenario for breakpoint recovery. When the power goes out, the controller loses its volatile memory. The program pointer, the current position, the modal states — all of it is gone. When power comes back, the controller starts from scratch.
Some modern controllers have battery-backed memory that preserves the program state through a power loss. If your controller has this feature, enable it. Set the controller to save the program state to non-volatile memory at every M00 or at regular intervals during execution.
If your controller does not have battery backup, you need a different strategy. Use M00 markers frequently. Before each M00, jog the tool to a safe height. When power returns, manually jog the tool back to the last M00 position, restore the work offsets from your written notes, and resume from that marker.
Using Single Block Mode to Control Recovery Points
Single block mode is your best friend during recovery. After a power loss or emergency stop, run the program in single block mode from the last known good position. Step through each block manually. Confirm the tool position on the DRO before pressing cycle start for the next block.
This is slow. But it is safe. Running a recovered program in continuous mode after a crash is how you get a second crash. Single block lets you catch errors before they become collisions.
Once you have verified that the program runs correctly through the recovered section, you can switch to continuous mode for the remainder of the job. But the recovered section always runs in single block first.
Handling Tool Changes During Resume Operations
What Happens to Tool Offsets When You Resume
When you resume a program after a tool break, the tool in the spindle is not the same tool that was running when the program stopped. The program calls for tool six, but you have tool eight in the spindle. If you resume without changing the tool, the controller will execute tool eight with tool six’s offset, and the cut will be wrong.
Always change the tool before resuming. Load the correct tool, set its length offset, set its radius offset, and confirm the T-call in the program matches the tool you just loaded. Then resume.
If the broken tool is still in the spindle, remove it first. Do not try to resume with a broken tool. The offset might be wrong because the tool length changed when it broke. Set a new tool, set new offsets, and resume.
Updating the Program After a Tool Change Mid-Job
If the program stopped because of a tool break, the T-call in the program still references the broken tool. You need to update the program to call the replacement tool. Change the T number in the program to match the new tool. Update the offset call if necessary.
Some controllers let you edit the program on the fly. Others require you to stop, edit the file, and reload it. Know what your controller supports before you need it. If you cannot edit on the fly, have a backup program ready with the correct tool number already set.
Best Practices for Breakpoint Recovery That Actually Work
Mark Every Major Operation
Do not rely on a single breakpoint at the start of the program. Place M00 after every distinct operation: after roughing, after semi-finish, after finish, after every tool change. This gives you multiple recovery points. If the program stops during finishing, you resume from the finish marker, not from the roughing marker.
The more markers you have, the less work you lose when a crash happens. But do not overdo it. A marker every two lines is pointless. A marker every fifty lines is risky. Ten to fifteen lines between markers is the sweet spot for most milling programs.
Write Down Offsets Before You Stop
Whenever you hit a breakpoint or stop the program, write down the current work offset values. Write down the tool length offsets. Write down the spindle speed and feed rate. If the program crashes and you have to recover manually, these numbers are your lifeline.
A simple notebook next to the machine is all you need. Date, time, tool number, H value, D value, work offset, spindle speed, feed rate. Five numbers per entry. Thirty seconds to write down. Worth more than any software feature when the power goes out.
Test the Recovery Process on Scrap First
Before you trust breakpoint recovery on a production part, test it on scrap. Run the program, stop it at a breakpoint, then resume. Verify that the tool goes to the right position. Measure the part. Confirm the dimensions are correct.
Do this once when you set up a new program. Do it again if you change the program. A recovery process that works on scrap might fail on the production part if the stock size or the fixturing is different. Test it under the same conditions you will use for the real job.
When Breakpoint Recovery Is Not Enough
Long Programs With No Markers
If you are running a program with no M00 markers and it stops at line four thousand, you have a problem. There is no recovery point. You have to resume from the beginning or find the last good block manually.
This is why markers matter. A program without markers is a program without a safety net. Add them. It takes five minutes to insert M00 calls throughout the program. It saves you hours when something goes wrong.
Multi-Operation Jobs With Shared Offsets
When a program uses the same work offset for multiple operations and one operation fails, resuming from the breakpoint can cause offset conflicts. The program expects G54 to be active, but after the crash you might have switched to G55. The offset values are different, and the tool goes to the wrong position.
Always confirm the active work offset before resuming. Check the DRO. Check the offset register on the controller screen. Make sure the program and the machine are using the same offset before you hit cycle start.
Five-Axis Programs and Complex Kinematics
On five-axis machines, breakpoint recovery is more complicated because the tool axis orientation is part of the state. If the program stops mid-rotary move, the A, B, or C axis position is critical. Resuming from the wrong axis position can drive the tool holder into the fixture.
Five-axis recovery requires saving the full kinematic state, not just the XYZ position. Some controllers support this. Others do not. If your five-axis controller does not save the axis positions on stop, you have to manually jog all five axes back to the last known good position before resuming. This is slow and error-prone, which is why five-axis shops rely heavily on simulation to avoid crashes in the first place.
Building a Recovery Routine You Can Trust
Every shop should have a written recovery procedure. Not a vague idea of what to do. A step-by-step routine that any operator can follow when the program stops.
The routine should cover: how to identify the last good block, how to reposition the tool, how to verify offsets, how to change tools if needed, how to resume in single block, and when to switch to continuous mode.
Write it down. Post it next to the machine. Train every operator on it. Run a drill once a quarter where you simulate a crash and practice the recovery procedure. The shops that recover fast are not lucky. They practiced.
A breakpoint recovery routine that nobody follows is useless. A routine that everyone knows by heart is worth more than any feature on the controller.
