What are some feed rates people have been using for their Maslow?
I see in the intro guide there are these recommendations:
What are people using (especially for the plunge rate)?
Iâve set up a wiki page for different materials here:
Hopefully folks will add in some successful rates and results and we can get some standard âfeeds and speedsâ together for the most common work materials.
I know Bar has reported using ~20-25ipm rates (bit type unknown) and the âtop speedâ is reported as 45ipm, but the machine doesnât corner well that fast.
As for cutting depths, i think conservative numbers = bit radius per pass, no more.
Iâve been pretty much running everything at 30 ipm with a .15 step down these days, but you can be more aggressive than that for sure. I think I leave the plunge rate at 30 ipm, but the firmware will limit it to make sure it can keep up.
one of the biggest complaints on the âtestedâ video is how slow the machine is.
It would be really useful to have someone do a bit of experimentation with
ânormalâ 3/4 plywood and test how aggressive the cutting can be (both in depth
and in speed). It would be useful to test both in the bottom corners, and nearer
the center of the sheet.
I think that the tested video was shot at 10ipm with a .1 inch step down so what took âabout 20 minutesâ in the video would probably be more like 4-5 minutes with the pretty conservative settings I normally run now. We only had one chance to have eveything work for that video so I was VERY conservative 
Out of curiosity, does being very conservative on z depth and thus number of passes increase accuracy? Obviously super aggressive passes at over 1/4" will cause drag and unpredictability, but at a certain point more passes just means more potential minor deviations at various depths as each pass isnât repeated identically right? It seems like under .1" and not only is it slow, but could actually be less accurate? Or is more passes always better?
thatâs the question, we donât have any tests showing that shallow cuts are
better or that aggressive cuts over 1/4" are worse.
I think thatâs a great question for which we donât have a good answer. A comparison test would be an interesting thing to run.
anyone doing this sort of test should do it in the upper center section (best
case for tension) and the lower corners (worst case)
just cutting circles out should be enough.
I might be wrong, but âcorneringâ is an important movement that will be impacted by increased feed rates. A circle might not be enough for testing.
Iâve read that some CNC type machines âslow downâ for corners, and then speed back up. Any thoughts of including speed changes when approaching a corner (of course defining a corner vs a curve may be interesting).
Iâve researched it as an option that I can set in Fusion360 but I still donât have a MaslowCNC (or any practical CNC experience for that matter).
I would guess that the 2 ways to approach it are:
CAM software just building it in as a function of its .nc file generation, prior to any CNC machine compensation of the intent of a given machine path. In the case of Fusion360, there was mention of Autocad-HQ being near Maslow-HQ and some form of active communication that might result in a MaslowCNC specific post processor, which i assume would do similar things as #2.
Ground Control interpreting the Gcode and applying some sort of processing to compensate for how the machine would actually respond to those raw commands. (by being aware of âslewâ or âsagâ (my terms) or degrees of accuracy and other MaslowCNC-specific machine constraints)
Acceleration, jerk, and higher order rate of speed change parameters are what youâre describing (look at grbl, Marlin, tinyg, Auggie, Mach3/4, LinuxCNC etc). At least LinuxCNC implements full stop mode between segments too.
With luck Maslow is following the 3D printer firmware trajectory. No acceleration, add acceleration and jerk (which gets you higher speed/better cut quality), and maybe the higher order parameters like snap, crackle, and pop. With the odd kinematics Bar started from scratch so itâs not surprising the harder stuff got left for later, and/or future more powerful controllers.
Itâll be a fun project. Now if I wasnât cutting 40 cords of firewood, fending off swamp rats, and still pulling medic shiftsâŚ
we do need to include acceleration into the movement planning at some point, but
the firmware doesnât do it now (we are focusing on accuracy first)
This means that faster feed rates will slightly overshoot in corners. But the
Maslow is not a particularly fast machine at itâs best.
The biggest question for feed rate is the best bit size and depth of cut.
The proper thing is for the maslow to know the rate that it can change direction
and speed reliably and then when told âmove from here to there, then turn and go
to that pointâ it would know how fast it can be going when it needs to turn.
the grbl code has a very good planning section in it that accounts for this sort
of thing. Once we get the accuracy worked out, we can copy that code.
What about increasing the depth of cut instead of feed rate? Ramping in instead of a straight plunge if thatâs a problem?
Time to make the trek to town for plywood instead of sawing firewood, then I could try it myself. Still have a few weeks until it starts snowing again
thatâs what needs to be tested. Early on Bar made a test where he cut all the
way though 3/4 plywood in a single pass at the fastest speed he could get the
machine to move. He was concerned about breaking the bit at that speed, but if
that really is a problem, moving to a larger bit would probably solve it.
We need to have people test this sort of thing and report the results.
The thing Iâm most excited about exploring is cutting very aggressively but a little outside the line, then coming back for a âfinishingâ pass. That way the accuracy doesnât really matter, except on that final pass where not much work is being done.
Integrating G-code generation into Ground Control would let us automate a lot of these things.
As long as the inaccuracy is away from the final part.
Roughing and finish cuts are a common thing, but you know that already . Just what does it take to break a 3/16 or 1/4" carbide bit? Precisebits.com has a max feedrate test procedure, basically increase speed until either the quality is unacceptable or the bit breaks, but theyâre in the bit selling business.
Found it (and a BBC test, too, click on âitâ).
I hand wrote the gcode for my Zenbot mini with 1/16 through 1/8" bits, worked pretty well and didnât break too many (cheap, not from them) bits.
while I see the attraction of trying to simplify things, please donât reinvent
the wheel. There are a lot of tools already available that will create the
g-code, and they all have strenths and weaknesses. Yet-another-tool for this
isnât nearly as valuable as making the firmware for the maslow work better
(faster, add acceleration/planning features, etc) that will help everyone no
matter what generated the g-code.
I donât want to be limited to using Ground Control any more than I want to be
limited to using Fusion360. The Maslow should consume g-code no matter where
itâs generated.
Once you start down the road of generating the g-code, you then want to tweak
what you are generating, which quickly turns into making another CAD program.