Decrease movement speed?

Is there a way to make the Maslow move slower?

Hi. This is usually done with the feedrate from you CAM program. Is there a specific reason you want to go slower? You could also look into the code, as ‘max feedrate’ is set there.


Yes, there are a couple of ways to do this. As @Gero said, this is generally done in the CAM program you’re using. It will be specified as “cutting feedrate” or “Max feedrate”.

It can also be done using find and replace commands in notepad. I will often do this if I’ve been experimenting with feedrates and need to quickly update a program. This saves me the time of messing around with parameters in CAM and gets me cutting faster. The following is a sample line of G-code:

G1 X9.2982 Y9.1685 F40

The last parameter, F40, specifies the machine’s cut speed. If you wanted to slow this down, you would simply run the replace command and tell it to replace all instances of F40 with F20:


Note: sample find/replace window shown is from Sublime Text. Depending on the text editor you use, the interface will look different.

Hope this helps! :smiley:


The maximum allowed speed has recently been added as a setting in the firmware. In the next few days/weeks, we can update GC so that users can easily alter this.


@krkeegan & other volunteers, thanks for your dedication! Sounds great.
Will we be able to change the speed live? ie, when the Maslow is running

Ummm, not really, at least not as I had envisioned this. The firmware has always had a maximum linear speed (maxSpeed) hardcoded into it, this has been set at 1000mm/min for XY. In theory, any feedrate that is requested that exceeds this number is throttled down to the maxSpeed.

This update allows the user to alter this setting without altering the firmware.

One could change the $15= value (the maxSpeed setting) in their gcode and it would work, but this isn’t really how this was envisioned.

Some day we may be able to incorporate a speed multiplier that could give you the ability to speed up and down the machine live, but we are a ways away from that day.

1 Like

I’ll second the feature request to have an on-the-fly change (like the FeedRate setting on the Marlin software) – the reason:
You have a whole lot of parts to cut (eg final frame skit), but after a couple of pieces are done, you find that your router is tipping out instead of cutting in.

You could stop, go back and re-path, re-export, and re-load, or you could press the “MultUp/MultDown” buttons in ground control to change the speeds by 5% each press (and the firmware would not let it go beyond the “max speed of the machine”).

This is something that’s fairly common in 3d printing, but very uncommon in the
rest of the CNC world.

In any case, you should be able to pause (as opposed to halt everything), enter
a command to change the max rate, and restart

it’s one thing to adjust the rate of an extruder flying around in space. the
worst that happens is that you start producing string.

But if you start pushing a CNC mill too hard, things can break (including
breaking the mill itself in extreme cases)

Oh, I know… I have a Bridgeport, and I religiously follow the feed&speed suggestions with it (but I sometimes get my X&Y signs mixed up when entering the CNC code from the front panel, so I still kill bits).

Ideally, I’d like the SpeedUp/SpeedDown buttons to only alter the “cut” speed, and I suppose you could make it safer by putting a 150% limit on the “up side” (in hindsight, I may have been cutting my plywood too slowly – it was making “dust” and not “chips”… which then fell into the handle and started to smolder – so I’d like to be able to go beyond 100% as long as it’s not “faster than the motors are capable of”, even if it’s “not much faster”)…

Definitely not a “fire and forget” machine like my 3D printer (at least… not yet)!

1 Like

I’ve found that it’s generally good practice to run at full speed, but reduce the depth of cut when I want to go lighter…but that’s tougher to do after the g code is generated :grimacing:

1 Like

Well, it’s complicated, but I was thinking of another feature request that might help both those:
Whenever Z changes, “bookmark the line”, when z changes again have an option to “recut” (go back to the boomark and re-execute the g-code) or “reset bookmark and go forward” or “go forward without moving the mark”). If you’re a manual Z user, you can just keep re-cutting it until it does what you want, and if you’re a driven Z user, it would be handy if you could adjust adjust the z offset in real time and have a checkmark for “enable z pause” to let you do the bookmark thing.

Could be dangerous if there was a move you weren’t expecting…
Maybe disable the “recut” if the current X&Y don’t match the bookmark?

Dunno. I’ll see what I think (I think tabs could mess that up completely) once I get the main sled cut.

What do you find is a good feed&speed for the 1/4" compression and upcut bits in plywood?
I know the build instructions said that 30mm/s was good, but it was making fine, flammable sawdust on me (I was using a 1/4" single flute hss bit, so that might’ve just sucked)…

I like 40 ipm with a .125" step down. Going even faster would be better, but that’s the limit of the hardware.


Even though that’s not the intention of the function written, it would be very useful to have the ability to alter the feedrates on the fly, i.e. make it cut 75% of the programmed feedrate. Many of the machines at my work have pendants with potentiometers on them to control both feedrate and spindle speed. That is probably a ways off on the Maslow, but it would be a good feature to add to the wish list :wink:

That’s a great idea on using this feature! I may have to use that as a way to test faster feedrates so I don’t need to change my firmware to do so. Could I write $15 = 2000 (for example) into the startup block of my code?

Or you could find/replace in the NC file like I suggested above. It saves the step of needing to tweak the settings in CAM, so it would speed up the process.

Ground control has a feature like what you’re describing. The Z step button moves you to the next/previous Z move in the G-Code:

I’ve had more than a few moments when I have to restart a program when GC froze or I had to E-Stop. This works pretty well to get back to where you left off. It always helps to note which line you left off on before stopping and restarting the program.

I have not tested 1/4" compression bits on my Maslow yet. I do have a couple that I got from the Maslow store from an order mix-up, but I have yet to use them. Theoretically, compression bits are designed to run at faster feedrates than up/downshear bits. Also keep in mind that two flute bits need to cut somewhere around twice the speed of a single flute equivalent (depending on flute geometry).

I have used a 1/4" single flute carbide upshear bit at 500mm/min @ 12000 rpm with 7mm max stepdowns for plywood and that makes pretty good chips. I originally tried it at 700mm/min but the bit sounded pretty overloaded, even at higher RPM’s.

Quick note, the machine uses mm/min as the feedrate when you’re working in metric. Does your code specify F30 as the feedrate? If so, that would be why you’re getting dust and smoldering, because that is wicked slow for plywood. If it is running at 30mm/s, that would convert to 1800mm/min, which is well above the 1000mm/min max speed for the machine. The firmware would reduce this to the max feedrate, in which case you should be getting pretty good chips with a single flute bit, even if it is running a little fast.


Again, I strongly caution I never envisioned allowing a change to the maxfeed rate on the fly, so it almost certainly has major issues.

The feedrate is only calculated at the start of a block, so if you pause and change the max feed rate, it likely won’t take effect until the start of the next block.

Agree, but this is a ways off. A lot of work needs to be done to the firmware before we are at a point where something like this would be possible. Grbl solves this problem by breaking each code block into 100s or 1000s of execution blocks, which is probably what we will end up doing as well.

All $ commands are persistent until written again. Since the feedrate command is not currently in GC, setting it using $15=n will be a permanent change through restarts until you write it again.

I know everyone wants their machine to go faster, but the sad news is that it just can’t with the current hardware. There are a few places near the center where vertical movements could be faster, but most of the horizontal movements are all maxed out around 1000.

Plus there is no warning when the machine can’t keep up, it will just start skipping the ends of code blocks.


Certainly. I figured this feature was one of those “no guarantee of success, use at your own risk” ones. So it would be a good idea to have the startup block say $15=2000 and have the end block say $15=1000 to revert it after the program concludes. That way the change does not persist after the test program.

Yes, I know that the limit is really in the hardware, not the firmware. I went through a couple of hardware options in this thread to fix the issue. I have some 25 tooth sprockets as @dlang suggested that I am planning on testing (you know, when I have that magical thing called time :persevere: ). If that doesn’t give me the results I’m looking for, I intend to look into 24v motors and the needed H-bridges to power them.

Definitely, I meant that as a “wish list” sugestion more than an immediate fix. I’m not an Arduino/Python programmer but I can imagine that is no easy feat.

Timing issues in CNC from my experience, happen in different ways. There is no “wait loop” in velocity. Physics in time space is a real problem.

I see it like this - a train is running at say 60 mph towards a bridge that suddenly collapses. The physics of the trains mass will not allow it to just stop and wait for the next bridge to be built.

For me, before I had the Maslow I was concerned the design was too flexible. It wasn’t until I ran the first final sled cut that I saw the speeds were not causing a problem, it didn’t move the way I thought. The current speeds and my temp build are safe, I have no flexing.

I’m sure we can improve everything to go faster. I appreciate it for what it is.

Thank you

1 Like

What was the bridge made from, toothpicks? :stuck_out_tongue: Also, depending on who’s building the new bridge that could be a long wait. If it’s a union crew, it’ll take a least a few years.

I jest, but I do love your examples. They help to illustrate the point in much simpler, less engineer-y terms :smiley:

Thank you for bringing this up. I too had a similar reaction to seeing the Maslow when I backed the Kickstarter. This could be a serious issue as well for faster feedrates, and was not something I covered in my previous post. I’m hoping my steel top beam frame is robust enough for these tests, but definitely could be more of an issue with a stock frame.

1 Like

For fun, I attempted to map out the maximum movement speed. I made the following chart. For each point, I calculated how much chain movement would be required for each motor to move the sled 50 mm in the Y direction and 50 mm in the X direction and selected the maximum value. I then formatted the cell colors to create the following. The chain movements required range from ~50mm to ~35mm in the sweet spot.

This means in that small window the maximum theoretical feedrate with the stock components is about ~1400mm/min.



That is jaw dropping work!

Thank you