Feedrate suddenly dropping during contour toolpath

I’m having issues with contour toolpaths for some reason. Every other type of toolpath is fine, but I keep having an issue where, right in the middle of cutting, the feedrate will suddenly drop to almost 0, and then jump back up again. Watching the machine it almost looks like the router is getting “stuck” on something for a second, that’s how drastic the drop is. I’m using Fusion 360 to generate the toolpaths and I can’t see anything there that might be causing the issue. I’ve seen a couple other posts of people having the same issue who weren’t using Fusion, so I suspect it’s something to do with carbide motion, but I’m not sure. Haven’t seen anyone else actually resolve their issue.

Side1ProtoEdge1.nc (311.0 KB)

This is the g-code file. Like I said, it’s happening during the contour toolpath at several points. Looking at CM, I manage to catch that it was happening somewhere around line 11 300, if that’s of any help. I don’t know anything about reading G-code so I have no idea what to look for.

Like I said, I’ve had it happen on several pieces now, always the 3D contour.

Sounds like a USB buffering issue. You’ve got a lot of small moves in there. If the computer is slow or you’re not using a quality cable, you could see something like that.
Try restarting the computer (what are you using by the way?), only open Motion, and run the code again.


I suspect you nailed it - it’s probably the cable. I guess it COULD be the computer - I’m using a 2020 macbook air, which should be up to the task just fine - but I’ve got the Nomad connected with just a cheap adapter I bought in a hurry off of amazon because I didn’t realize when I bought the laptop that it has no USB port. I’m vaguely familiar with different cables having different speed capabilities, but not enough to realize that it’s something that could actually cause an issue. Case in point: I just checked, and I had the machine plugged into the USB 2 port, even though my adapter also has a USB 3 port. I just used the one that was closest to make sure the cable has some slack while I’m sitting on the couch lol. I’ll try switching it to the other port and do a test run, and if it’s still having issues, I’ll get a new adapter.

Thanks for taking a look at the g-code, I appreciate it.

Actually, USB1 should be plenty fast to saturate the serial connection the machine uses, and we’ve found that on some computers, USB2 is more reliable than USB3.

1 Like

Interesting. So you think it’s not the cable that’s the issue at all? Any thoughts as to what else it could be? I didn’t have this issue until fairly recently, despite doing a lot of the same kind of cutting, and I used to have the machine plugged directly into my desktop PC. Could it be the laptop, then? It’s powerful enough to run Fusion alright, you’d think that would be enough to just transfer some g-code, no?

I run my 3XL from a 2013 MacBook Air, so it is unlikely to be your computer that is the source of slow-down (unless you have antivirus or something that nobbles USB performance?)

1 Like

We’ve seen Grbl get starved for G-code when the communication/control program bogs down — usually this happens due to other programs running on the computer causing CM to swap out.

1 Like

I did several test runs and experimented with cut tolerance and smoothing values in Fusion, and having looser tolerances (and thus simpler g code) does improve the issue, though doesn’t solve it completely. However, I NEED my tolerances to be as tight as possible for my project to work. I tried playing around with a bunch of settings in the toolpath, and while I didn’t test cut all of them, nothing changed the file size more than make a kb, so I assume it won’t make a difference.

I also tried increasing the CPU priority of CM to the maximum possible value. Made no difference. I tried disconnecting my webcam (it connects to the same adapter as the Nomad), and shutting down every program except CM, and it makes no difference. I don’t understand why this is happening. What is it about the 3D contour toolpath specifically??

I’m not sure if what I’m saying applies to your case, but the following has happened to me and I’ve also seen it mentioned on the board. In Fusion, sometimes you can end up with “plunging” toolpaths where you don’t anticipated it. I’ve had cases where say instead of moving from (X1, Y1, Z1) to (X2, Y2, Z2) at a regular feedrate, it thinks it needs to plunge (thus has greatly reduced feed rate) and may also loop all the way around the part the long way. This is something you can catch in your preview and simulation and correct with different bounds or such. The first time this happened I was thinking controller malfunction, but it turned out the CAM was the issue after inspecting the toolpath more carefully.


I’d discount the computer as a bottleneck here. It has to send 310kb over a period of many minutes over a USB to serial interface, which is trivial for that computer.

There is probably no buffering on this type of protocol since it sends one instruction at a time and I think each is acknowledged before the next is sent (I might be wrong about that).

edit: looking at the posted file, the the areas around line 11300 do several sequential operations of almost 100 moves each, that move the spindle less than a millimetre each time. Could that be what you are seeing as “pausing” ?

1 Like

Grbl includes a planning/look-ahead facility — so as to keep the machine moving more quickly/smoothly — say one is cutting a circle which is made up of a bunch of polylines, the look-ahead allows it to move smoothly through an approximate circle, but it’s limited to a certain number of moves.

I suspect you (@Gerry ) are correct and that this is overwhelming the planner.

1 Like

At this point I’m just going to simplify my contour toolpaths as much as I can (I realized I had it set to 1.5mm stepdown when it’s not at all necessary to be that conservative on this piece) and move on with my life. Lol. It’s an annoying problem, but I’ve at least been able to conclude that it’s a consequence of trying to cut such small, intricate shapes. It doesn’t seem to be negatively affecting the final outcome, and if I take a little extra care to maximize efficiency, machining times should still be reasonably low.

Thanks everyone for your input and suggestions.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.