CNC routing arbitrary circles

OK - here’s a strange one. I’m cross-posting between the Vectric and Snapmaker forums to see if anyone can shed some light on this problem. Here’s a pic of the end goal.

So I’ve created a roughing path with a 3mm end mill, but every 4 layers or so, it decides to route a ~6cm circle centered on a point about 1cm diagonally outside the corner of the work boundary. It seems to happen about every 4 layers and the first one was on the bottom left corner.

The last one went out of bounds of the wood (first time circle) and slammed into the side about 2mm down so the end mill couldn’t cut the line like it had one previous circles.

I’m more than a little baffled and hoping someone can look at the .cnc (gcode) file to see whether this is coming from the vCarve output and being interpreted strangely by the Snapmaker or if it’s in the generated code coming out of vCarve.

Rosette 3D Roughing 1 Top.cnc (1.0 MB)

And then hopefully a means of fixing it!

For reference I also generated a 3D Finishing route with a ballnose which did not have this issue.

And a little feedback from the vCarve forums that are pointing towards a bug in the Snapmaker’s interpretation of the G2 commands which makes sense as it seems to be based on the arc it’s trying to cut around the inside points of the corner cuts. This also makes sense since on the bottom right circle, you can see that the deeper cut which came later is offset from an earlier one which lines up with the edge of the circle on the inside point.

Latest firmware I assume? If so, you could try to compare the g-code between Luban and vcarve, or fusion360 and vcarve to find out if it’s software bug.
If g-code seems alright, Support Ticket Form with the model so they can try to identify the bug.

It’s the latest firmware and after some more feedback, it seems to be a bug in the Marlin library used in Snapmaker. Someone pointed me to where it previews Marlin gcode which displayed exactly what the Snapmaker tried to cut, even though the gcode doesn’t include those arcs.

A support ticket has been opened.

And the result of the ticket is that the Marlin code they’re using doesn’t properly support G2 & G3 commands. But the workaround is to preview any models using since it appears to use the same library and will show the badly interpreted G2/G3 arc cuts. For roughing passes, you can generally just delete the G2 lines and the arcs will get routed out by the subsequent actions so it’s not a big problem.

I tried another simple job to cut through a board with tabs and this one generated G3 arc commands that generated the circles in ncviewer so I tried replacing the G3 commands with G1. The result is that it was no longer an arc cut in the corners, but converted them to straight lines, which was OK for a simple cut routine.

G3 Arcs:

G3 commands replaced with G1 (simple search and replace)

Upshot: always preflight your jobs with ncviewer and either remove or replace the G2/G3 commands.

1 Like

Oh, and the cut worked fine, but the rocking of the Snapmaker pulled things slightly out of alignment, but it’s still a pretty good proof of concept for when I get access to a machine with a fixed bed.

1 Like

Thank you for updating the post, sucks that it is this way. Did they mentioned of it will be fixed?

Unfortunately, no ETA given, but I did reach out to the maintainer of ncviewer to get pointed to the GitHub repository where I’ll be filing a bug once I figure out which repo has the current Marlin library.

Looks like it’s been an ongoing issue with marlin from 2020, nobody could fix…

Grrrr. At the very least there are workarounds.

1 Like