Stuttering along curves

Ok, was using my XL tonight to cut out some simple address numbers for a friends house and when it was milling the curves it would stutter here and there. Only on curves not on diagonal travel or ortho travel. It left the some chatter marks on the wood when it was all said and done. I ran the job without wood and the router off and it was still doing it. Checked all belts for slipping and set screws. Ran again with no wood or router and it was still doing it. Now here is what I don’t understand. I made the job in Fusion 360 (which i’ve done before) and was trying to rule out issues, so I remade the job in Carbide Create and ran it without wood or router and it ran smooth. Same speeds and everything. The only difference was that CC ran the circles counter-clockwise and F360 ran them clockwise. Would this be a stutter in a motor?

here is a link to the video of it stuttering…you can hear it as well.

Thanks in advance!

1 Like

CNC’s need to cut in Climb mode (ALWAYS), because the motor’s are not strong enough (or get over worked) cutting conventional. See the helix and rotation of the cutter help pull it along (almost self feeding, so all the stepper motor does it slow it down. Meaning very little energy on the stepper motor in climb mode. Hope this helps

Just to add to this, Fusion 360 will let you select one or the other and some times both depending on the type of cut you selected.

Also never say always because it depends on materials as well as other things.

This is what is in the wiki:
"Unless your machine is very rigid… you should always do conventional cutting"
Another recommendation is to climb mill for roughing passes and conventional mill for finishing passes.

Yeah, I tried hard to have it both ways in the wiki, since when collecting the bits for it, both ways came up.

I suspect the Nomad represents a new class of very rigid, but low torque machines and that we will need to work up the best practices for it, and that these will be markedly different from best practices for the Shapeoko (or maybe not — perhaps the give of the belts results in the same issues @RichCournoyer noted.

Another consideration is that what works in one material may not work in another, e.g.,

… except on low surface energy plastics (HDPE, Polypropylene, etc).

A final consideration is that for wood, grain and its orientation can be a significant consideration for some species — I can still remember a piece of southern yellow pine I was whittling on in my youth — that tree must have had one incredibly cold and long winter at some point in its past 'cause there was a slow growth ring which was markedly thicker than any other in the piece, and which was significantly harder than the other slow growth rings in the wood (which in turn were markedly even harder in comparison to the fast growth rings than usual).

Maybe this is a dumb question, but why would it still be stuttering when I ran a test job without cutting anything? The machine wasn’t under any stress/influence from a piece of stock…that’s what was confusing me.

If it stutters when there’s no load, then we’re probably looking at a software problem.

The Arduino has a very small buffer which is used for look-ahead, and if that buffer empties, then the machine has to slow down, since it doesn’t know where it will be going next and it has to be prepared to either stop in position or change direction.

My suggestion would be to see if there’s an option to enable generation of curves and enable that. Also try a different G-code sender (ISTR that there’s been reports of Carbide Motion being unable to send certain forms of G-code fast enough) — if the different G-code sender works better, send the file to so that they can use it as a test to fix this problem. EDIT: I now see that you did do this after a fashion (creating a file in Carbide Create and sending it successfully using Carbide Motion)

ok, thanks Will! I will look into that

When my xxl was doing that it was v-wheels not adjusted correctly.

I will look at that as well…I have them just tight enough that they don’t quite spin freely…

I tighten mine till they don’t spin and then make sure belt is good and tight.

Suggested tightness for V-wheels:

loosen the eccentric spacer until the v-wheel does not rotate when the carriage is moving and then tighten just (and no more!) until the v-wheel rotates when moving the carriage.

I’d say that’s about how tight mine are…I made sure not to over tighten them when I assembled it. I will be running another job this weekend, so I will see if it was just Fusion 360 issues

1 Like

Re-reading your first post, it’s almost certainly software / communication caused by too-short moves in the G-code not being transmitted by CM quickly enough — my apologies for taking so long to realize that.

Please share your G-code file w/ — they need to work out a way to make use of any code from Fusion 360 — do please however check your post-processor — might be that changing that would address this as well.

1 Like

Thanks Will, I have sent 320 programs to the Shapeoko in the past year, and never experienced this problem, but will keep this in the back of my mind. Learn something every day.

“Carbide 3D” is listed in Fusion 360’s post processor…I’ve just been selecting it each time I post process. Would there be a better format to try?

I use carbide 3d post on fusion 360… have you had this issue before this? if so have you changed anything in the CAM?

There are a couple of different ones listed on the wiki: Shapeoko CNC Router, Rigid, Accurate, Reliable, and Affordable

Some discussion of working up an improved one here:

Carbide3d.cps (generic GRBL) is what I’m post processing with in Fusion…I will check out the links


Have you tried out any other g-code senders per Will’s suggestion? I would recommend ChiliPeppr or Universal Gcode Sender to start, my favorite being Chilipeppr… I too think it’s a communication issue that may be resolved with one of these.

Good luck,