I’m using a 60 degree engraving bit to carve a pattern into a wood surface and I consistently get a ripple on the sides of curves. The carriage runs very smoothly and I’ve ensured that the rollers and tubes are very clean. I’m using Fusion 360 to generate the gcode with (I think) the latest post processor.
The same pattern remains after running it multiple times without changing the home position. Interestingly, it occurs when I keep the same X and Y and drop the Z 0.3mm.
I’m thinking this is a gcode generation issue. I’ve not used Estlcam. Has anyone seen any of the same or different results with Estlcam or Fusion? I’d really like to get this cleaned up. Thanks for any pointers.
(I want to get this figured out before tearing down to do the Burly upgrade.)
My first guess would be tool “chatter” or some other consequence of imperfect stiffness. I dont think gcode is likely because it’s easier to make smooth curves than it is to make bumpy ones.
But you are saying it is consistent. Maybe something about the wood like nonuniform hardness could be inducing the repeatable pattern? If you make a second copy and it has the same marks in the same places then it would be more convincing that it is something with gcode (or firmware).
The traditional remedy for chatter is a finishing pass, but I’m not sure if the same rules apply to engraving with a V-bit. That’s essentially what you’re doing by lowering just a little so I’m not sure how you would fix it. A finishing pass traditionally runs slower too. Thats the only thing I can think that you might do differently.
Yeah, that’s what I thought at first also, and I looked at mechanical movement, cleaned up tensioned surfaces, checked belt tightness, etc. I’m cutting at 40 in/min with a depth of only about .125 inches and spinning at 20,000rpm. There is no chatter and each cut is exactly the same as the previous. In lieu of a finish pass, in case it was chatter, I simply reset the Z to .3mm deeper and the exact same pattern reappeared.
Got any experience with other programs generating engraving code? Fusion has been great, but I’m starting to doubt its gcode generation.
I imported an SVG canvas into Fusion and used it as the generation layer for this cut. Perhaps it’s interpreting the curve as too short of segments and not using the built-in curve commands.
Are you using arcs? Arcs are marginal in some versions of the firmware, in particular it can be momentarily sluggish in some curves, which can leave artifacts in the workpiece. Can you see the speed being irregular?
Does your bit/mill definition have and of the trochoidal elements (oscillation, width, step length) defined? That could result in a regularly recurring pattern and would likely amplify it if you are using a separate pass to do a finishing run with the same mill setting. ( at least as far as I understand these things)…
Well, I tried it using Estlcam and the results are a lot better. Some of the positioning is not as good as cuts are interrupted a lot in the Gcode, but the finish on the edges is much better. Even though cutting marks show, I can’t feel them by running my finger over the beveled surface. I did note the carriage moved a lot more smoothly for this one.
What I don’t understand is why the positioning is different for the interrupted cuts. This picture shows the dislocation in a groove to the far right. It’s only a fraction of a mm, but still. The Fusion output was better in accuracy than this.
So, I think this shows that the Gcode is the culprit. Needs further investigation to figure out positional inaccuracies.
GaryH: I cannot find any variables or characterization of these tools in either Fusion or Estlcam. All the cuts are made in a single grooving pass, so no trochoidal movement.
I would expect different results for different spindle speeds if what I think you’re saying is correct, but I don’t.
There is a setting in the gcode generator on fusion to pick how many segments to subdivide your curves into… set it too high and the board can’t keep up and movement is not smooth. Set it too low and the curve isn’t smooth. I had to increase the value from defaults to get smooth movement around curves.
Now that’s very interesting! I’m looking through the postprocessor code and only see some “arc support variables”. (MPCNC_Mill_Laser from Martindb Feb 2018).
The only problem with them is they appear nowhere in the code and don’t appear to be used. Unless you’re referring to another Gcode config section?
I’d very much like to see what you changed up as it would make my toolchain much cleaner than going through Estlcam.
Yeah, these are not very heavy cuts. The photos are very close. The deepest is .125 inches. Not even close to load limits at 40 in/min.
I simulated a finishing pass by rerunning from same coordinates at 0.3mm deeper. Same pattern so I’m sure it’s a gcode thing. Some of the artifacts (not the ripple) seem to have their source in the SVG import file as it was derived from photoshop.
I’m now looking at Greg’s pointer to the post processor and arc/segment subdivisions.
Getting much more interesting now. I found the toolpath generated by Fusion from which the Gcode is produced. All are linear moves (no arcs). It looks as if the finest movements are on the order of 0.5mm in both X and Y on the same step. This kind of resolution could easily be the cause of the ripple I’m seeing when translated directly to Gcode.
By contrast it looks like Estlcam generates steps along the curves on the order of 0.1mm long with many in the 0.01mm range. This is most likely why that cut was much smoother.
I cannot find any settings in Fusion to increase the resolution. Greg, is this where you found some configuration variables?
Ah-ha! Looks like this is all determined by the “Tolerance” variable in the Operation definition. Moving tolerance from .01mm to .005mm made a ton of difference. Looks like I’ll be able to keep using Fusion for carving like this.
Sorry for the multiple posts; just couldn’t let this go.
Glad it worked for you! Yes that’s the setting I tweaked.
Strangely I had to go to the other way… mine defaulted to 0.001mm and I had to change it to 0.01mm to keep up with my feedrates. Based on your post I’m going to try backing it off to 0.005mm
Yep. Here it is in hard maple where I had the original problem. This cut is entirely equivalent to the Estlcam cut. I think I could reduce the tolerance even further without data starvation, but don’t think I need to.
One other interesting point is that this gcode file is still only about 60% the size of the Estlcam file. I did notice the Estlcam algorithm was not nearly as efficient, but that likely does not account for that much of the size difference. I believe they are by default using a higher tolerance, and if that file didn’t result in starvation then even further tweaks to the Fusion parameter would probably work. I suspect .003 would be just fine.
