Gcode Curve Support?

[DeadlyDad]

I was searching for a gcode exporter for Inkscape so I can print smooth lettering/etc. and came across your project. I don't code well enough to be able to parse your code, but does it support the G02/G03/G06.X commands that generate curves for the hardware to interpret? That would both make the resulting gcode MUCH smaller while making the fabricated part match the original artwork MUCH better.

Here is the video that introduced me to the commands: https://youtu.be/18uYYXecH5g

[arpruss]

No, it doesn't support these.

[DeadlyDad]

Would you be willing to add them? G02 and G03 are just circular arcs, so they should be fairly easy to implement. The difference in print quality just from Arc Welder is pretty spectacular, and that is just from approximating the original curves.

[Ohmarinus]

Would you be willing to add them? G02 and G03 are just circular arcs, so they should be fairly easy to implement. The difference in print quality just from Arc Welder is pretty spectacular, and that is just from approximating the original curves.

Honestly I can't really see segments in the lines. Why would you want G02 and G03 if the results from this script are already nice and sharp? Also, I think it's more work than you may think.

[DeadlyDad]

Would you be willing to add them? G02 and G03 are just circular arcs, so they should be fairly easy to implement. The difference in print quality just from Arc Welder is pretty spectacular, and that is just from approximating the original curves.

Honestly I can't really see segments in the lines. Why would you want G02 and G03 if the results from this script are already nice and sharp? Also, I think it's more work than you may think.

Here are a few reasons:

1. File size. Each single-command curve can substitute for dozens or even hundreds of line segments, thus drastically reducing the size of large, complicated models.
2. Accuracy. Breaking a curve into line segments results in an approximation of the curve, which can cause problems with fitting later, ESPECIALLY if describing a hole; the line ends are on the curve, which means that the hole will always be smaller than specified.
3. Smoothness. While it is entirely possible to define a curve with enough segments that they aren't visible, that only really works well on small objects; a 1cm circle made of 30 segments looks fine, while a 1m circle... doesn't. Using G02/G03 will result in the same resolution no matter how large the curve. (Yes, it is possible to define the maximum segment length, but to make a 1m curve look smooth could require thousands of segments.)
4. Hardware-independent resolution. Just like the resolution abstraction offered by PostScript/PDL/etc., using G02/G03 will mean that the controller itself will determine how to best draw the curve, based on its physical limits, rather than setting an arbitrary value.
5. Speed. It takes time for the controller to interpret each command; fewer commands mean more time spent working and less spent 'reading'.

and, finally and most importantly,

6. Standardization and best practices. Hardware like CNC machines expects to be given defined curves rather than line segments. They know how to deal with them to provide the very best output.

Does that make sense?

[arpruss]

I expect that not all 3D printers support these gcodes. Moreover, a lot of the time what comes out of Inkscape or other svg drawing programs will be splines, not actual arcs, so I think the utility will be limited to cases where the user took care to ensure there are arcs.

But most importantly, I think this is just begging for bugs. Getting these gcodes right is finicky, and there are multiple cases to get right, and I think it's safer to just deal with lines. You can get whatever precision you want by upping the precision in the generator. Granted, it will make the files bigger.