Not sure what is going on, have latest firmware and ground control running, have recalibrated a few times over but ecery time i try to cut a new sled i get this for the inner circle.
Is this because i am usin a .nc file from makercam and not a .gcode file.
Numerous reinstalls of ground control and firmware and then calibrations and keep getting same problem, any ideas as going crazy trying to figure it out.
Hi. That is not nice. 
Sating you have latest Firmware and GroundControl is a hint, but the version numbers showing in GC would be better, as we have latest release and “bleeding edge”.
I assume it shows up in GC as a circle? Can you take a short video wile it’s cuttig?
Further following information would be helpful to dial in.
- operating system
- standard chain brackets or what linkage kit
- upload the .nc
- is the kinematics type set correctly (did you change that setting at any point)
Kind regards, Gero
1 Like
The use of nc code from makercam is not the problem (it’s what you are supposed to use).
Definitely post some pictures and/or video of your setup. I assume you are using a temporary sled and a temporary frame (since you are trying to cut a final sled). This suggests you are using the stock components and are using quadrilateral kinematics. Take screenshots of your Maslow Settings and Advanced Settings and post them as well. I’ve not seen a circle so bad (congrats on winning the worst circle award! 
)
We’ll get you there.
2 Likes
Would you also post your. “NC” file here for us to look at?
Thank you
The thing is, I have used 2 different files with the same result which is weird, so not sure its the file but maybe both are bad, attached file below.
I am using standard frame but still using the temporary sled. I tried to cut a full sled but mucked up the file/cuts in makercam so made a new file.
Shows up in ground control as circle.
Here is the setup
here is the file
sled.nc (92.3 KB)
using old laptop with no problems so far
been cutting things nicely so far
windows 10.0.15063 on i3 Asus notebook
re-downloaded latest ground control windows portable v1.02 (6 jan 6.39pm) to see if this would fix it, it did not.
also re-downloaded firmware 1.02 at same time and uploaded to Arduino, same result.
2 Likes
you can put the file in https://nraynaud.github.io/webgcode/ to see what the g-code is actually saying to do
1 Like
the file looks good in the simulator
unless you started with the Z in the wrong place, that looks vaguly like the path to drill the holes.
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.
k
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.
2 Likes
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.
2 Likes
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)
https://youtu.be/GJkYxNHZY-8
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.
log->>
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.
https://youtu.be/tTb99TDXjsc
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. 
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