Caught a bug: incorrect processing G2 and G3: arc processing error with commands G2 and G3

[Goodfeat]

Hello, I found a problem when processing the g-code with the G2 and G3 commands.

The problem is that the firmware repeater and the repeater host process the arc so that the arc is drawn outside of the printer.

I am using firmware repeater host 1.04 and I use repeater as an analyzer of g-code. For slicing, I use the cura software version 4.10 in conjunction with the Cura-ArcWelderPlugin

when I cut a file and try to print using the printer, the printer tries to process the incorrect line for the repeater firmware during printing. at this time, the printer tries to make a movement outside the printer, thereby damaging itself

this is the line where the problem appears

and here you can visually see what the host is actually drawing

this link is used to discuss this issue with the plugin developer @FormerLurker
https://github.com/fieldOfView/Cura-ArcWelderPlugin/issues/23#issue-965621817

[FormerLurker]

@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:

Repetier-Firmware/src/ArduinoAVR/Repetier/motion.cpp

Line 2208 in 2bbda51

//float linear_travel = 0; //target[axis_linear] - position[axis_linear];

Repetier-Firmware/src/ArduinoAVR/Repetier/motion.cpp

Line 2244 in 2bbda51

//float linear_per_segment = linear_travel/segments;

Repetier-Firmware/src/ArduinoAVR/Repetier/motion.cpp

Line 2284 in 2bbda51

//arc_target[axis_linear] = position[axis_linear];

Repetier-Firmware/src/ArduinoAVR/Repetier/motion.cpp

Line 2317 in 2bbda51

//arc_target[axis_linear] += linear_per_segment;

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.