Making a v-carving with a 90deg. 12mm bit. Svg in estlcam to make the g code. Set the speed at 700mm/min for xy-movements and 100mm/min for z-movements. Router goes 10,000 rpm in 1/2" ply.
It is agonizingly slow to carve: Actual speed is around 10-30mm/min. Why is it so slow? Any suggestions to speed it up?
Next day, same carve x-y speed went down to .5 - 1 mm/min. Z-speed appears to be about 100th of a mm per second, not 100mm/min! There must be some sort of software issue?
Any suggestions on how to troubleshoot? I.e. how could I check Z-speed setting on Arduino?
I’m using estlcam 11.043, latest version of GC and Arduino Firmware. (posted also on Facebook group)
1 Like
What is the speed in the g-code? Easy to edit with ‘search and replace’ in a text editor.
2 Likes
Thanks for your quick reply, Gero!.
I did look at the F-parameter. It is only set once in the header but not changed from there on. Here are the first few lines of GCode:
(Project Haida_Tree_by_kireihiryu)
(Created by Estlcam version 11 build 11.042)
(Machining time about 00:27:47 hours)
(Required tools:)
(Engraving bit)
G21
G90
G94
M03 S10000
G00 Z5.0000
(No. 1: Carve 130)
G00 X31.7955 Y63.9890
G01 Z-6.0000 F700 S10000
G01 X31.8025 Y63.9371
G01 X31.8100 Y63.8853
…
Also, when starting in the middle of a gcode program using the go-to command (after pausing for the night and then resuming the next day), what speed would it choose, since it will not hit the same F parameter again?
Thanks,
Andy
1 Like
it would keep using the F700 for all future movements
but your limiting factor is probably going to be the Z axis andthe speed it can
move.
the other possible limitation is the time it takes to process each line of
g-code. If you have lots of short movements, that can take a long time to
process (which is an arduino performance limitation)
David Lang
2 Likes
I see the G94 that i believe to be not supported by the Malsow FW/GC.
In the ‘code snippet’ there is a F for the Z-Axis. From other programs like linuxcnc i know that the last F for each axis is stored and maintained until changed. As far as i know this also applies to G0, G1, G2/G3.
Not sure how Maslow handles this. If your G1 commands have no F for G1, what does the Maslow use as speed.
Main question: What post-processor in estlcam did you use to create the g-code?
bCNC, LinuxCNC, Mach3 are simple enough to run with Maslow GroundControl.
Edit: ‘grbl’ instead of bCNC
Edit2: GC instead of Maslow.
2 Likes
I used the GRBL postprocessor, so that should work. Assuming it keeps the F700 or goes to the default of F800, the actual speed is waaaay of the mark and much slower that the Maslow could go.
Maybe it does come from the large number of instructions, very small movements.
Still, it would be good to be able to diagnose that. Is there a performance monitor for the Arduino? Can I see that the CPU is at 100% or Memory is full, etc.?
I’ve attached the gcode file, if you’d like to check it out.
Haida_Tree_by_kireihiryu.nc (2.8 MB)
2 Likes
I think this is the issue. I bet that because the feedrate is not set you are seeing strange behavior. Try running those first few lines and then using go-to to see if that solves the issue. Go-to can be a little dangerous because things like the feedrate and the units are not set so you can have inch/mm conversion issues also when starting a program in the middle.
2 Likes
Looking at the g-code, you are right. Almost 100000 line of gcode could be the clue here.
Check for an accuracy setting in estlcam to reduce the amount of ‘splines’.
2 Likes
Somebody’s ported Maslow kinematics and motor control to these? That’s not a trivial task…
1 Like
Indeed not trivial, I mean that using the post-processors creating g-code for this software will most likely work with GC. Sorry for the misleading post. Edit done.
3 Likes
Thanks Bar, that brought the speed back up to what it was initially.
It is still pretty slow at around 20mm/min, but that’s probably because of too many statements/excessive accuracy.
Adding default settings for unit of measure (i.e. mm/min) and Z-axis speed might be a good requirement for a future release.
1 Like
Thanks, Gero. I looked but could not find a setting for spline accuracy. Even a web search did not produce any results. Any suggestions where to find that setting? The only accuracy related settings are in the estlcam cnc controller settings, but I believe that refers to an alternative to Groundcontrol, so we aren’t using it.
1 Like
The Estlcam manual suggests this is an issue in your CAD software and not Estlcam. You may want to find something else to create your original text or whatever you’re carving.
Inkscape has some curve simplification tools that I’ve found tricky to use at times. Worst case you might need to do some (maybe a lot) of manual editing.
Worst thing I ever engraved was a pencil sketch one of my young (at the time) daughters did. Inkscape’s curve tracing turned it into tens of thousands short segments and phenomenally long cnc times. Several hours of manual editing (of the picture, not the gcode) changed that from many hours to a few minutes
1 Like
Interesting! Yes, I did use inkscape to turn the jpg into a vector graphic. I had another carving that was just somewhat simpler and was a whole lot faster, this might explain why.
I’ll have to find out more about reducing complexity/splines in inkscape.
2 Likes
Thank you for the clarification. Previously, I worked 6040Z and used Mach3, the program is certainly not the best, but I got used to it. I am trying to understand whether it is possible to use it with Maslow. As it seems to me, the main problem is to adapt the motors, since the movement along the x and y axes in Maslow differs from 6040z. But is there anyone who has already done this?
the big problems with carving on the maslow are:
-
there is a delay between sending each line of g-code to avoid overrunning the
buffer (the grbl version should be much better at this) -
the Z axis is very slow, so anything with lots of Z motion is going to be
limited by this.
nobody has ported the maslow kinematics to any other system yet. There is a grbl
version that’s running, but is missing a lot of subtle tweaks needed for top
accuracy, but it’s probably pleanty good enough for typical carving projects
where absolute accuracy across several feet doesn’t matter as much.
David Lang
2 Likes
Just to close the loop here: I did try it with a much simplified vector graphic, i.e. reduced number of nodes to less than 500 and that greatly improved the speed. Like others pointed out, the complexity is really just an issue for Z-Axis movements. Once you get into the fourth decimal for Z-movements, it kills the data flow and grinds the carving to almost a halt. I’m starting to learn about ‘data starving’…
3 Likes