Can't cut circle - it cuts a squigly squashed star instead

That looks to me like what I would expect from a sled with not enough weight on it to keep the bit in the wood. Is it possible that the weight of the sled changed or the angle of the machine changed?

1 Like

Sled and angle have remained constant, I am running the whole recalibration again now.
I made a new file up using easel and will run that and the original again, if that doesn’t help I will roll back to ver 1 and try that

1 Like

Has been running beautifully for weeks up until this strange behaviour that haven’t been able to work out why, update soon after full recalibration

he is running the temporary sled with no bricks on it.

No luck after another full calibration, although interestingly, this time the left top quarter of the circle cut as a circle but the went back to weirdo stuff.

Ditched the file, used a new one I made up on easel and worked fine.

I saw F1500 in the file for cutting circle… this, I assume means 1500 mm/min? Converting to imperial units, this puts the feedrate at 59 inches/per minute which, I believe, is too fast for the Maslow. Maybe with the temp sled and max feed rate caps, this caused the problem?

1 Like

That’s the speed i have always used and everything else has cut out fine. I think it is something in the way makercam exports an .nc file, as i have only started using that as opposed to renaming exported makercam gcode as .gcode as I have done on all other files.
Certainly frustrating for sure when maslow has been cutting things great.
Perhaps i should reduce the speed, broke a 5mm bit today. What is recommended speed for ply and MDF.

I’ve never had to rename makercam files (just use the .nc) and it’s worked well for me. I think as far as feed rates go, 40 inches per min is pretty good. I sometimes run much slower when I try to do very intricate cutting.

⁣Sent from BlueMail ​

So easel worked fine? Uploading the .nc helped. I think I figured out what is going on.
Would you be willing to cut the file again with the following setting changed in GC?
(turn on Truncate floating point numbers)
That will tell us if I’m on the right track.

Edit1: Apologies for not asking first if it was turned on. That would throw me off this horse.


Hi @Gero , yes the file i generated and exported from easel worked as normal. Yes I will change that truncate setting to on and will try again on the .nc file.
I am curious too if that setting will change the outcome.

Thank you @madgrizzle i will try that speed setting for future cuts too.


Can’t tell if this is realy the thing that you are seeing because im not running on a live Maslow.
It is a Mega without motor shield or anything attached, so my finding might be off the real world.
I have replicated some weird teleportation of the sled and recorded it. (FW/GC 1.02)
At 0:44 a buffer overflow hapens. I can find that in my log.txt in the GC folder.
I think it is line 12 in the .nc:
G3 X212.497461928934 Y214.63959390862942 I32.121827411167516 J21.829949238578678 F1500
throwing things off.
Buffer overflow!
Buffer Used: 127
Buffer Number of Lines: 0
Buffer Begin: 87
Buffer End: 86
Buffer Contents: G3 X218.129441624 Y209.979695431 I27.461928934010153 J27.461928G3 X224.002538071 Y206.812182741 I18.39593908629442 J27.06852791(End of Buffer)
With truncation turned on, it runs smooth.
Kind regards, Gero

1 Like

that is too many digits past the decimal (the machine isn’t accurate nearly
that far), truncating the numbers after three digits is still far more
accurate than the machine.

Without actually checking that looks like trying to shave pieces off electrons. Must be quite an edge on that bit. :grinning:

That suggests that GC could be rounding numbers to 3 or 4 decimal places to save space as it buffers the entire file in memory

Yes, with truncation turned on, 4 decimal places. That should be enough for mm and inch :slight_smile:

1 Like

GC does have truncation turned on by default, and truncated numbers to 3 digits
past the decimal (digits beyond that are so far beyond the capability of the
hardware that it makes no sense to process them, and they can make the lines
long enough to cause buffering problems)


How about removing the option to turn if off in GC if it makes no sense, at this point, to ever disable truncation? Leave the code there in case in the future it is useful, but just disable changing it.


GC has truncate=0 for a default. Just checked it :wink:

FWIW I run with it off and haven’t had an issue I could trace to this for a very long time. Work on the serial buffer had helped a lot!

Also FWIW, the issue in this thread doesn’t seem to be resolved by truncating the floats to three places.


bad usb cable or interference?

Looks like no Z-Axis is installed, so this could be related to the buffer overflow with manual Z. Either way, With FW/GC 1.03 this should be fixed now.
Did you give it a try?

Haven’t had a chance to try it out, will do this weekend. Also will run the file anyway rather than stopping it to see if it just the circle or the whole cut that’s wack.

1 Like