> Frank, did you come up with the algorithm yourself? or is there a reference (web-link, paper) I could read somewhere?
I just hacked the code. The original comments say it was based on the "Douglas-Peucker simplification", but because of the way it subdivided the gcode commands, it would end up with multiple G2/3 commands for the one arc. It was easier to "dumb" it down and just process the gcode sequentially rather than try and join arcs together. > This would be very useful for opencamlib also. For slic3r G-code I guess you can assume all arcs are in the XY plane, for opencamlib I'd like to extend that to XZ and YZ planes also. > You have two tolerance parameters. From a user perspective only one tolerance, the maximum deviation from the arc to the programmed g-code lines would be preferable? Yes, that makes sense. The tolerance for segment length could be calculated from the deviation tolerance. I added the second tolerance (line length) because the algorithm didn't work when zig-zagging across a circle (3d print fill). Because all the points were on the circle, it created an arc rather than fill. > Is there a maximum and minimum allowed radius for the arc? (a straight line is in theory just an arc with a large radius :) There's nothing that prevents that except the tolerances. I tweaked the tolerances until I stopped getting curves when I should have got lines. The tolerance was made very small. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
