Caught a bug: incorrect processing G2 and G3: arc processing error with commands G2 and G3 about repetier-firmware HOT 1 OPEN

@repetier,

First, thanks for taking a look at this! I know arc code in general isn't as mature as other commands, because until recently they were rarely used, especially in 3d printing.

It is a numerical problem that comes from the test if a circle is closed. This causes non circles like this to get converted into 360° circles with radius around 180m. I have now reduced this to a simple line sine a circle of 0.000006rad can be approximated very good into one line segment.

I hope this will help, but there is a much easier and more accurate way to test for a full circle. You can just check to see if the starting and ending X and Y coordinates are identical (or nearly identical), in which case you can set angular travel to 360 degrees or -360 degrees depending on the command, as is done in the current version of Marlin. The z parameter should be ignored in this case, since a full circle can have z axis motion.

Speaking of z axis motion, I also noticed that z motion is ignored for arcs, which will prevent G2/G3 from working while printing in vase mode:

As long as you are making changes to the PrintLine::arc function, you might as well enable z axis motion too. Arc welder supports generating arcs in vase mode.

If it would help, I would be willing to take a look at that function and attempt the necessary changes. In any case, I'll also add Repetier arc planning to my ArcStraightener algorithm as an option, which will make testing the algorithm a bit easier. It basically converts G2/G3 to G1 commands, and you can use any visualizer to test the resulting paths. This is my go-to algorithm for figuring out various arc planning issues in Marlin 1 and 2.

Also, regarding this comment:

I think fixing on arc welder would also a good idea:-)

Arc welder already had restrictions on the maximum arc radius, though the defaults were set too high for broad compatibility obviously. This has already been remedied, but for other firmware compatibility reasons. Some firmware has buffer overrun issues when receiving long gcode commands. This problem can also cause issues with other long commands, so it wasn't specific to arcs. However, as a happy coincidence, the new defaults should prevent this issue for the current version of Repetier as well :) I'm now using 9999mm for the default, as a 10M arc curvature can still be easily seen when printed on a large build plate. I still want to avoid hard coding a value here, but the defaults should prevent issues in the future for older implementations.

Also, this isn't really relevant to the issue at hand, but I wanted to mention that ArcWelder will not generate full circles ever. It was developed for 3D printing, and the only good use case I can think of for generating full circles is while printing in vase mode. Otherwise the extruded plastic will overlap at the starting coordinate. It may make sense to do this for vase mode prints, but I figure the extra complexity just isn't worth it. In the current code, either a new arc will be started, or a G1 will be used for the final segment if the following commands don't follow a curved path as defined by the resolution.

Again, thanks for taking a look! I am always VERY happy when I see improvements to the various arc interpolation algorithms! I know ArcWelder has caused some pain for the various firmware developers, but I am willing to help relieve a bit of the burden if at all possible.

from repetier-firmware.