Decrease movement speed?

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


Thank you big time for this great work you are doing.
I missed such detailed data.

Blunt question, why are we cutting there the most accurate? (at least April 2017)

Because there are many factors that contribute to an accurate cut and we have the chain positional accuracy pretty well dialed in. Other factors that are better at the center include less drift due to the load being mostly on one chain. The math also was more accurate at the center, but this could be getting better now.


This comment is also entirely wrong. I have deleted the chart to avoid propagating inaccurate statements, but left the rest of my wrong comment here.

old comment totally wrong, don’t believe a word of it

I was thinking about this more and realized my conclusion about accuracy is probably wrong or at least a bit misplaced. This is the same chart selecting for the minimum value. This shows the chain movement necessary to cause a 50mm movement at that point.

As you can see, out at the edges it gets as low as 8mm (edit wow even ~3mm infact) of chain movement to cause a 50mm error. While the middle still hovers around ~35mm.

So my conclusion was completely wrong. The prior chart is a good means for determining where the machine can move the fastest, but this chart does a better job showing where positional errors have the greatest effect.


I dunno, something still seems off about these numbers. The general chart seems right, but something strikes me as wrong about 3mm causing 50mm in error.

1 Like

Wouldn’t that 3mm be cumulative to that point?

No, what I tried to do was take each of the points on the grid and do four calculations to determine the amount of chain movement:

  1. difference in the amount of chainA at start point and then Y-50mm
  2. difference in the amount of chainA at start point and then X-50mm
  3. difference in the amount of chainB at start point and then Y-50mm
  4. difference in the amount of chainB at start point and then X-50mm

Then depending on the graph, I took the min or max value. I was initially trying to determine where the sled can move the fastest based on our limited motor RPM.

Again, the appearance seems right to me, but something is off about those numbers at least in the second minimum case.

That doesn’t sound right. The point where a small chain movement results in the
largest error is in the top center where the angles are shallow and the tension
the highest, at that point a small error in chain length can result in a large
vertical movement

rather than looking for what causes a 50mm error, plot how much error a 1mm
error in chain length will result in.

There is no way that a 3mm error in chain length will result in a 50mm error in
position anywhere on the sheet.

It does seem like at the side edges most of the error would come from the closest motor, and so be close to equal to the movement from there…?

Has any one designed a layout cutting a 3 inch X in the 4 corners and the middle of a 4x8 sheet to test this?

Thank you

1 Like

@krkeegan Those charts are an excellent visualization! If I gather correctly, you’re saying 1400mm/min might be possible near the center of the machine with stock hardware? It’s funny, because I’m nervous about pushing that with the stock hardware, because I know funny things can happen when you push hardware to their limits.

I also know that the other issue that could arise from raising the feedrate is acceleration planning. With all the other awesome tasks you’re handling, the last thing I’d want to throw into the mix is adding that to the firmware. When the time comes, I would gladly do some of the testing on my machine. Until then, I found that Fusion360 will handle that before post, so I will program it into my G-code.

Not that exact test, but I have detailed a pretty thorough bed accuracy test here. This test is actually still a HUGE priority of mine, as it will tell us much about both the machine and the linkage systems. It actually supersedes any feedrate tests. I need to finish cutting my test sled, and then I will be running them.

1 Like

In the usual moosely tangent this suggests a “high performance” mode for projects where you’re willing to trade accuracy for speed, or have a project where you use roughing and (slower but full depth) finishing passes, perhaps by limiting speed by max motor RPM.

It also suggests a phase II super Maslow with more powerful motors, lower gear ratio, and more PP motor R encoders, and an accompanying higher current motor driver. Ties nicely into a 32b faster clock processor too. Add me to the prospective upgrade kit wait list

My numbers are right, I am just reading them incorrectly. On the minimum chart, when it says 3mm in the lower left corner it is correct that the left chain only needs to move 3mm for a 50mm move to the right. However, moving the left chain 3mm by itself won’t achieve that result the right chain needs to move nearly 50mm as well.

So I am going to remove the minimum chart as misleading and correct some of my statements above.

Yes, but again I really can’t stress enough how badly things mess up when the machine can’t keep up. It isn’t just a case of a few rounded corners. An inability to hit the desired feedrate causes a cumulative error. So longer cuts, particularly those in a single direction could be an inch or inches short. And so on.