I know what you mean. As I see on ShapeOko 2 doesn’t seem that fast. Looks like Tool path changing speed by other factors like diameter of the circle, chipload, dept ETC. I’ve seen real speed test on somewhere cutting MDF Cabinet doors at blazing speed on long edge side, slowing down about half way on short edges and fillets.
You mean in the video I posted? The very first set of motions is traversing the outer X-Y axes bounds. At 35,000mm/min with 290mm travel in both X and Y, you should finish the round-about traverse in about 2 secs. Checking the video, it’s about that.
No I believe you, I thought you speed up the video.
While I am thinking about it, what were the changes made in Grbl 9j. Is there any pressing reason to upgrade from 9i?
Try calculating the time it takes by the distance it moves.
I thought that’s what I did with calculating that initial traverse.
With any acceleration-bounded motion controller, you have to slow down into corners and speed back up coming out of them to not exceed the limits of the machine and motors. So the machine execution time is always greater than the programmed time. That is a pure and simple fact. This is because CAM tools don’t account for physical acceleration limits of the machine and just assume infinite acceleration. However, the greater the acceleration bound, in this case 4000 mm/sec^2, the closer you get to programmed time.
I deleted the tool path that was shown in the video long ago, but this is an experiment you can try yourself. Setup Grbl, disconnected from a machine and any electronics, so just the bare Arduino, program the ‘$’ settings to those in the video, stream a tool path to Grbl, and time how long it takes to complete that job compared to what the CAM tool says its supposed to be. You’ll probably find that its very close, and closer as you increase the acceleration settings.
1 Like
Sorry, I just read “about” and thought it was a guestimation.
With our raster feedrate test file, it took 12000 mm/sec^2 accels set for the X&Y to get the toolpath to time correctly with the set feedrate. Does that accel sound correct for grbl’s max?
Yeey, we have two Wikipedia start talking each other. Sit back and learn. 
Com-on SungeunJeon question to you.
If your target feed rate is about 5000mm/min, then yes. Grbl approximates an acceleration curve with 8ms constant velocity segments. At 8ms, you should hit over 5000mm/min from a start from rest. So it’ll look like there is infinite acceleration in the machine with a 12000 mm/sec^2 acceleration setting, and the actual machine time will either match or be very close to the programmed time.
If your target feed rate is more than this, you’ll start to see actual machine times become slower than programmed time again.
The feedrate we tested was 175IPM and we actually ran our Shapeoko 2 through the motions when running the test file. It’s a raster file with a .006" step over & step ahead and runs at a 45 degree angle. The perimeter of the X&Y travel in the file is 340.8066 inches and it takes 1:57 in time when using the 12000 mm/sec^2 accels. 340.8066/117sec=2.9128*60=174.768IPM. Pretty darn close to 175IPM. Very impressive results! If we set the accels to 10000 mm/sec^2 it takes 3 seconds longer. Accels at 1000 mm/sec^2 takes 27 seconds longer. This is when set $11=0.005.
If anyone wants to test the feedrate with the grbl there using, grbl settings and performance of there gcode sender, here is the feedrate test file we used. There is no M03 or Z axis moves in this file. Only X&Y and it’s in inches. It’s set at 175 IPM and should time out at 1:57 min (117 sec).