Hi. I’m working on carving a sign, and it seems the speed is pretty slow and jittery. Not sure what is effecting it. I have the feed rate at 50 mm/s (up from 15 mm/s that was initially recommended). Thing is I have already run this project before and I don’t recall it being so slow the first time. But then again I was pretty excited it was even working. Regular engraving paths seem to be fine (speed wise) Is it normal to be slow when carving? Video attached may be poor, I have to convert from iPhone to Windows to shrink it down). Ignore the duct tape nightmare that is my dust baffle. FWIW, I’m running on Rambo 1.4 with a Raspberry Pi Zero W feeding it. The artwork comes from a traced bitmap in Inkscape maybe not the smoothest boundries.
On a related note. I am trying to cut painted MDF in this case. As you can see I am getting paint folding back on the edges. I am not sure if it’s relate, but I noticed if I rerun the same job, where it re-cuts it gets smoother some (sort of a finishing pass). How to I get carve to make a finishing pass on purpose? I tried setting the allowance, but it just runs the same regardless. Meaning it does not appear to be going back to clean up. The paint folding may be because it is not fully cured too. It was just painted today.
Thanks in advance for any advice you might have about either issue.
Look at your g-code and see if you have large numbers of very small moves. I have seen this happen on Estlcam’s carve feature. Here is an excerpt from one of my jobs:
Since it is moving purely in X, I know this is sub-optimal (putting it nicely) and not a question of resolution. It’s quite annoying and I have considered getting SD support purely as a workaround for this.
This might not be your problem but it is something relatively simple to check.
That does seem to be a possibility. Here is a piece of the file I was running. Looks like pretty small moves. What I am running is a small portion of a previous job to test cutting thru paint. I looked at the original job file I as well and it does not seem as dense. Wonder if I changed something I shouldn’t have in Estlcam.
Hmm, my math is not working out like I thought it would.
At 250k bits per second
you would get about 25 k bytes per second
which is about 1000 commands per second if each command is roughly 25 bytes
which would be 100 mm/sec if each command is a 0.1 mm movement
which would be 6000 mm/min feed rate top speed, which is sufficient for the requested feed rate.
And yet I see jerky, slower than expected movement that appears to correlate with large numbers of tiny movements. Perhaps it is not the communication speed but the computation speed of the Mega 2560 that is the limitation? I was already considering adding SD support as a workaround, but now I want to add SD support as an experiment to see what happens…