Bit plunges at the end of the program

Generated G code in Fusion 360, and used Repetier Host to run the MPCNC. At the very end of the milling, the bit plunges straight down into the material, instead of lifting up out of the piece. Where should I start when looking for a culprit? The G code doesn’t appear to have any erroneous Z coordinates that indicate a downward plunge.

Here is a video of what we see just before it happens. The Z axis maxes out at - 9 for some reason, even though the tool travel is not maxed out. It registers changes in X and Y, but Z becomes useless. It then plunges down into the work piece, but the travel depth is not registered because it’s maxed at - 9 on the readout.

I imagine it’s gonna be a setting in F360. I’ve had the issue before but don’t remember the source.

I’m assuming your using a V1 firmware. Have you watched the simulation on f360?

Yes, V1 firmware. Fusion 360 doesn’t appear to show the final plunge issue during simulation. The forum won’t let me attach the F360 file.

What path type are you using? 2D contour?

Show us the last 20 lines of your gcode.

1 Like

Yes, 2D contour

Here is the G Code (sorry for the quality)

M84 at the end. That disables the steppers, so the router will drop under its weight. There’s a setting in your post processor for that, just disable it.


I’m curious how the heights tab looks in F360. I think that’s what I’d check first.

I agree with Barry. This was my guess before I saw the gcode.

It will drop more often while the router is running. Because of the vibration.

Barry and Jeff are right, and additionally this is way too fast which can produce unexpected behavior
G1 Z4 F2000

1 Like

I have to say that this has been beyond discouraging. We’ve spent so many hours trying every fix on every forum and it’s still going on. This is the program that is running now. We changed the feed rate, we deleted M84, nothing worked. We tried M84 S0 because one site said it would keep the steppers on - that didn’t work. Now we’re trying M84 S1000 to see if that works. So far, every single thing we’ve tried has resulted in the bit being plunged into the piece immediately after the program ends, ruining what would otherwise be a perfect job.

1000 is still a bit fast but probably not the issue, it might vibrate in place but shouldn’t overtly stab your work.

I don’t use Repetier Host, but I would imagine it also has configurable gcode fragments on job start, job finish, job pause, job resume, maybe others too like abort. Check that there is nothing suspicious in those, in particular at job finish. Can you show the settings for those?

What about manually removing the “M84 S1000” line at the end before running your code?

I just checked some of my files, and I don’t have an M84 at all…I just M0 to remind me to shut off the spindle.

While you’re there, you could add a G1 X0 Y0 to move to a safe X/Y before ending the code also.

Also, does the tool rise up to Z=15 before plunging? If so, then it’s got to be some extra code like in the job completion macro.

You could confirm this by running from an SD card where RH is not part of the equation. Then you can be extra sure it’s doing only what is specified in the gcode file.

I’m almost certain it’s an F360 setting guys.

I really don’t understand how disabling the steppers would drop the toolhead, though I’m still running the threaded rod tool assembly so I can perhaps believe that the lead screw tool assembly can more easily move the Z just by gravity.

What I’m seeing in the gcode is your cut finishes at a depth of ~2mm, then the tool rises to 15mm above the origin plane. Then you say the tool drops into the material.

Does the tool rises to 15mm appropriately? Does the tool try to home at the erroneous plubge depth? Do you have safe homing on in your post processor? Are you using one of the recommended MPCNC post processors for F360?

Look for a “parking” option to move the gantry to a desired location at the end of the job. In addition to shifting your tool drop so it only spoils the spoilboard, it’s nice to have the tool move itself out of the way to remove the workpiece.

Anything unexpected that F360 or the post processor is doing would have to manifest in the gcode since that is the mechanism for conveying everything to the downstream process. Whatever strange settings there may be, the outcome is reasonable, so even if some settings are wrong, they can’t be the cause of the problem. (Or more precisely, they can’t be the cause of the problem separate from the gcode.)

1 Like

Where would we look to do that? Somewhere in Repetier Host?

The Z values on the Repetier Host screen don’t update because the screen is actually just showing the Command that is being sent, not the actual position. And, once you shut the steppers off with M84, they won’t know where they are anyway.

There’s nothing in the code that you’ve posted that shows a plunge to Z-15, so that leaves “unprogrammed” movement, which is this case must be gravity.