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.
3 Likes
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! 
4 Likes
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.
4 Likes
@krkeegan & other volunteers, thanks for your dedication! Sounds great.
Will we be able to change the speed live? ie, when the Maslow is running
gcode?
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 
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.
2 Likes
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 
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.
2 Likes
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.
3 Likes
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 
). 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? 
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
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.
6 Likes
2 Likes