Support for G2/G3 Controlled Arc Move

[ChainsDD]

G2/G3 definition

While I've not seen a slicer for printing output G2/G3, I also use my printer for laser engraving, and it's a common command when generating G-code from an SVG. Currently I have to flash Marlin back onto my printer before using my laser for that reason.

Marlin handles planning arc moves here and here, but I haven't dug enough in the Klipper code base to figure out how to implement it here.

[hg42]

look at cruwaller's fork, he has implemented G2/G3 (though I havn't used it)

[ChainsDD]

You're right, found it.

It looks like his implementation is directly pulled from Marlin, and doesn't seem to take advantage of the different way that klipper works, but it does give me a good starting point to work on my own. Thanks!

[KevinOConnor]

Feel free to submit a "pull request" if support is added (ideally, the arc support would be in a new file in klippy/extras/). I'm going to close this issue for now.

[JohnEdwa]

It's been a year, anyone willing to have a go implementing this? I promised to plot some wedding invites for a friend in a few months and I'd rather like skipping setting up Marlin again just for it if possible :)

[danielkucera]

Someone should have mentioned here that this has been recently implemented: https://github.com/KevinOConnor/klipper/commit/7d8c70363a4241ce7c16868e347d7c0f7855f5f3#diff-71420708e69755e8a44d7e3eac23cf1b

[mdelanno]

I work on a slicer that takes BRep geometry as input. When I slice a cylinder with a vertical axis, I get a circle and I can generate a G3 command. I was wondering if it would be possible to generate real arcs/circles (not a batch of linear moves but the adequate pulses to drive the motors in a circle trajectory) with Klipper and if so, would it be complicated?

[jalanjarosz]

Klipper does support G2/G3 arc moves using I’s and J’s

https://github.com/KevinOConnor/klipper/blob/master/docs/G-Codes.md#g-code-arcs

Thanks! James

On May 11, 2020, at 6:39 AM, Maxence DELANNOY notifications@github.com wrote:



I work on a slicer that takes BRep geometry as input. When I slice a cylinder with a vertical axis, I get a circle and I can generate a G3 command. I was wondering if it would be possible to generate real arcs/circles (not a batch of linear moves but the adequate pulses to drive the motors in a circle trajectory) with Klipper and if so, would it be complicated?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/KevinOConnor/klipper/issues/202#issuecomment-626622833, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJYADF4N3P2IUI5JLNRRVQ3RQ7IVHANCNFSM4ES37BSQ.

[mdelanno]

Yes, I know that... My question is: can a real circular path be generated instead of a succession of G1 commands?

[jalanjarosz]

Current slicers read in .stl or tessellated 3D models. They cannot create arc movements from models containing flats.

If a 3D slicer can read a solid model, native or B-Rep, and can create G2/G3 moves, than the printer can print arc movements.

At the moment, Cura, Slic3r, Pursa Slicer, etc. cannot do this.

It’s more likely, as MCAD machining apps mature to include additive manufacturing, this will happen here first.

On May 11, 2020, at 7:59 AM, Maxence DELANNOY notifications@github.com wrote:



Yes, I know that... My question is: can a real circular path be generated instead of a succession of G1 commands?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/KevinOConnor/klipper/issues/202#issuecomment-626658088, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJYADF6TE7L5I6JLAZMS2STRQ7SDFANCNFSM4ES37BSQ.

[JohnEdwa]

That is exactly what G2 and G3 are for. If the slicer generates a G2 arc move, Klipper will execute it as a G2 arc move.

[EDIT] Ah, you mean somehow going from a mesh to arc moves. That would require some sort of interpolation/fudging as the information is simply not there.

[mdelanno]

My slicer (Fanplast1k) is working in AutoCAD. I use the functions provided by AutoCAD to slice the model so I get a composite curve with arcs or circles. I translate them in G3 commands (I always turn in counter clock-wise direction).

The current operation (conversion of G2/G3 to G1) produces an acceptable result if the resolution is small, but I would like to know if we can go further and do without this resolution.

[KevinOConnor]

I was wondering if it would be possible to generate real arcs/circles (not a batch of linear moves but the adequate pulses to drive the motors in a circle trajectory) with Klipper and if so, would it be complicated?

It is possible, but it's not easy. Klipper currently uses an "iterative solver" to find precise step times for every linear move. It should be possible to change Klipper to find precise step times using the same "iterative solver" with non-linear moves. However, doing this would require updating Klipper's look-ahead code to handle non-linear moves. (See the docs/Kinematics.md and docs/Code_Overview.md files for further information.) That would be notable work, and it is unclear if the result would be a sufficient improvement over the current G2/G3 "line segmentation" method.

FWIW, since G2/G3 commands only handle circular moves (and not other common arcs), I'm not convinced those commands have actual value. As such, I'd add "implementing new arc commands" to the list of notable work that would need to go with the above.

Cheers, -Kevin

[Peuqui]

Hi, this guy is developing a plugin to convert G1 into G2/G3 code to reduce code and stuttering. It seems a highly promising piece of software: https://community.octoprint.org/t/new-plugin-anti-stutter-need-testers/18077

Regards

[mrx23dot]

The gcode post-processing app is ready, it takes G1 linear moves and merges them into G2/G3 arcs (where it makes sense), it can reduce the gcode size by -90% for pipes. https://github.com/FormerLurker/ArcWelderLib/releases

bin\ArcWelder.exe -l=INFO -p --allow-dynamic-precision --path-tolerance-percent=0.05 --resolution-mm=0.05 in.gcode out.gcode

The goal was to also reduce shaking/stutter by not using the slicer's crude linear lines for arcs. But according to Kevin the same thing happens in Klipper. The best we can do is to turn up the resolution on Klipper end until raspberry doesn't overload.

[gcode_arcs]
resolution: 1.0
#   An arc will be split into segments. Each segment's length will
#   equal the resolution in mm set above. Lower values will produce a
#   finer arc, but also more work for your machine. Arcs smaller than
#   the configured value will become straight lines. The default is
#   1mm.