Experiencing pauses during machining?

I’ve been running into some pausing while machining. At first I justified it to bad tool paths or weird things with engraving and tiny imperfections in the source file.

Last night I bored a hole with a simple helix op.

During the ramps down, it pauses. The F360 operation if I simulate is “ramping”. The output gcode is just a bunch of G1’s.

If I recall, it looked like it would do 360 degrees (while going down in Z as well), and then pause for a second. Repeat. Fusion thinks this is a 43 second operation, and while I know that can depend a lot, this was 3 minutes, no doubt because fusion doesn’t expect the tool to be doing nothing during the helix/ramp.

I’m thinking it’s likely something in Marlin I have misconfigured? Has anyone run in to this?

Last time I had issues with pauses and curves, it was because I projected a hole from a part to a sketch. The projection looked like a circle, selected like a circle, but was really a crapload of points. The direction change was hitting the JD or something and slowing things down a ton.
Not a super popular problem, but an obscure one and easier for you to identify than for us, plus I’m still stinging from that one a little, lol.

In this case I’ve draw a circle and it’s not a bunch of points, just a circle.

image

But yeah, that’s what I suspected for the engraving previously, the letters/fonts seemed to have some points so I just ignored it. This would be something different though.

1 Like

I guess post the gcode then, because you’re right. Once it starts the helix it should start helixing and not stop until it gets to a cutting depth. From the picture, it looks like it should go down quite some way before addressing the contour of the circle. There may be something to learn by looking at the model and the manufacture space, but it sounds like you and fusion are both doing your parts.

pausing-holes.gcode (105.7 KB)

Here’s the gcode.

It is a catch 22.

If you make small circles from many G1 commands, then each G1 command can take longer to send to Marlin than it takes to finish it. The reason this is a problem is that Marlin doesn’t know what is coming next, and to stay within its acceleration limits, it has to stop and start again.

If you replace thesw commands with arcs (G2/G3) then the transmission is no longer the bottleneck, but then the little cpu has to compute a bunch if trig and can bog down.

It sounds like you have the first problem. You can try to increase the transmission speed (the SD card is the fastest, then 250k on a good USB cable). Or you can try to use arcs.

I have arcs enabled in the marlin firmware. I have an SKR so cpu should be ok.

Is there a fusion setting or post processing setting I missed?

1 Like

Aha! I had to enabled “Allow Helical” in the post processor. Allowing “arc” wasn’t enough!

2 Likes

Glad to hear that the SKR is up to the task of doing the math for arcs My poor MKS Gen board isn’t, and it pauses all the time doing arcs, which is the (only) reason that I’m upgrading the board, because I don’t want to change the CAM to line segments. You can see the segment starts and stops in the finished work (Though probably a little sandpaper would deal with that.)

Well, I will report back on that one… but… i think the SKR should be plenty able.