I’m having a peculiar issue with my Maslow and I’m hoping it will mean something to someone here.
I am troubleshooting cutting small circles on the Maslow. When I generate a circular pocket using JSCut, it spits out gcode that is hundreds of G1 (linear move) commands. When cut on the Maslow with Ground Control, these circles are very close to true. I’ve posted an example of the working gcode here and here is a photo of the resulting cut:
When I do a similar circular pocket in Fusion 360 (post processing through the Maslow post) it creates gcode with just a few G3 (arc move) commands instead of the hundreds of G1 commands. That seems reasonable enough to me. But when I cut them on the Maslow using Ground Control, the circles come out all oblong and weird.
I’ve posted an example of the gcode that doesn’t work well here and here is a photo of the resulting cut (intended to be two concentric circles at two different depths:
Both input gcode files look correct in Ground Control and simulate correctly using NC Viewer. It’s just the cut itself that is nonsense when using the G3 commands.
Does this ring any bells for anyone? Any thoughts would be greatly appreciated.
One additional data point: I tried doing the same cut at a much slower speed. No change in the result. I got the same weird little almond shapes, just very, very slowly.
Not to talk to myself indefinitely, but: I just found the buried setting in Fusion 360 to turn off arc commands in gcode. So, I’m going to try that out tomorrow and see if it truly makes a difference.
Where on the board were the cuts performed? If the G1 file was cut in the center, but the G2/G3 file was cut off near a side, that could indicate more of a calibration/performance problem and not a gcode interpretation problem.
Hi guys. Thank you for the replies; I really appreciate it.
I’ve done a few more test cuts this morning and I have some updates:
First, the title of this post does not seem to be correct. I don’t think it is an issue (at least not solely) of G1 vs G3 commands. I did a test cut using Fusion 360’s “disable arcs” setting, and it demonstrates a similar problem.
Here are two test cuts right next to each other on the board. The left is Fusion 360 gcode with arcs. The right is Fusion 360 “disable arcs”.
Both wonky, skewed almonds, especially in the center circle.
Now, here’s the same shape cut from gcode generated on JSCut. It’s about two inches over on the board (you can see it off to the right in the above pictures):
It’s not perfect, but it’s a lot better than the Fusion 360-generated cuts. It is mostly an oval and not skewed or bumpy. By my measure, it’s about 1/16" wider than it is tall on the outer circle. I’m not going to win any calibration awards for that (and, of course, I’d love to fix that too…), but it would probably be good enough for my purposes.
So, long story short, I seem to have an issue with gcode spit out by Fusion 360 but not by JSCut. Which is weird, since they look awfully similar in NC Viewer. Here are the Fusion 360 gcode and the JSCut gcode.
I think I can probably eliminate this being a Maslow / Ground Control issue (1/16" calibration aside). But if anyone has any thoughts on how to get Fusion 360’s output to play nicely with the Maslow, please do let me know.
On your F360 code, it looks like the cut depth is 15.875 mm whereas on JSCut it is 6.35 mm. If you are trying to cut that deep (15.875 mm) I would expect some issues as you’ve shown. With a 1/4-inch (6.35 mm) bit, I think you are pushing the limits at a 6.35 mm depth per pass… 15.875 mm would certainly be challenging for Maslow to handle. General rule of thumb (and it’s just that) is a depth of cut equal to one-half the router bit width. So if using a 1/4-inch (6.35 mm) bit, depth would be 1/8-inch (3.175 mm) per pass.
Your pocket cut operations are in the wrong order as it start cutting the smaller/lower circle before the bigger/top circle material has been cleared. This results in a very aggressive first cut depth of 15.875mm.
I have found that on Maslow the first cut is the most important as subsequent step downs seem to follow the first pass and do not recover well from unevenness in the first pass.
Your best bet is to simply reorder the operations so the top circle is cut first. That should make a significant difference. I think this is the better way to go. If you keep you current order then wiggle from the lower circle may translate into the top circle.
If you want to keep your current cutting order then the smaller hole has the “Top height” set wrong. It should be “Stock top” and not “Hole top”. That should results in at least four passes.
If the result from using the above steps are still not good enough then slow down speed to 250mm/m. If that is still not good enough then look into doing a finish pass of about 1.5mm.
The “bore” operation uses a helical ramp cut by default and produces very good results but takes a long time. I can’t remember if it clears the center material if the hole is bigger than 2X bit diameter so you may need to do an extra step.
Thank you, everyone, for the assistance. I finally got back to cutting today and made a lot more progress with a clearer head.
@madgrizzle and @tinker were quite right about the main issue: the ordering of the two pockets in the machining setup in Fusion 360 did not make sense, and was leading to a lot of the issues I was seeing. With that corrected, I’m now getting similar results between Fusion 360 and JSCut.
Next, to see if I can shore up my calibration a bit… I’m beginning to suspect that my frame is not sturdy enough to get to the accuracy I want. But that’s tomorrow’s problem.
Glad that its working better for you. I did some cutting today and got the best results so far. Speed, or lack there of, is the key. Here are the settings I used:
On Contour and Pocket cuts use
Multiple Passes:
Max Roughing stepdown: 6.35mm (.025")
Use even Stepdowns: Checked
This will slow down movement to Feed Rate at Feed Distance measurement away (before and after) from any corner that is over Maximum Directional Change OR under Reduced Feed Radius. This was probably the most important thing I did. You can see the reduced feedrate displayed as yellow tool path in Fusion 360 preview.
Smoothing:
Tolerance: 0.01mm (0.004")
This will get rid gcode that uses distances that the Maslow cannot possibly achieve and so will reduce gcode size without sacrificing quality.
Bore:
This was way to slow but created perfect circles.
Ramp Feedrate: 300mm/min (12ipm)
Pitch: 1mm
You could probably quadruple the pitch and still get great results. With 1mm pitch it took 10 seconds to go down 1mm! I am going to do some testing on this next week.
These dog bones did not have the corners pre bored. They were a one step pocket cut! The bottom knock off cut error was caused by lack of supporting material along bottom edge.
Very nice! I’m quite jealous of the accuracy you’re getting there. I get (very) good precision on repeated shallow passes, but everything I cut is a little squished vertically.
I’m going to have to take a couple of weeks off from cutting. But hopefully when I get back to it shortly I can shore up my frame a bit and improve the output of my setup.
The squished issue is a calibration settings problem. I highly recommend a laser measurement device to get accurate build and test calibration pattern measurements. These are pretty cheap at hardware stores now. I got significantly better precision after using one. The better laser have min/max distance measurements, where you sweep the laser over target, and it reports the longest/shortest distance.
I get (very) good precision on repeated shallow passes, but everything I cut is a little squished vertically.