Reprap Firmware and Controlled Arc Move

Just curious ... I noticed that most of the other firmware have already implemented G2 and G3, but not RRF. Are there plans to introduce this in the future ?

This is kind of a let down so to say... I was trying to plot something (first with a pen, later will use a Laser) and noticed that my drawings are not what they should look like. There are a lot of G2 and G3 commands in the G file that the Duet just ignores. I am using Inkscape with the J Tech laser plugin. Any way around it ?

I think you are the first person to ask for support for G2 and G3 on RRF. Slicing programs for 3D printers don't generate them. What application are you using that does?

I'll add G2 and G3 support to the firmware wish list.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I think you are the first person to ask for support for G2 and G3 on RRF. Slicing programs for 3D printers don't generate them. What application are you using that does?

I'll add G2 and G3 support to the firmware wish list.

Controlled Arc Moves (G2 and G3) are generated by other tools not intended for 3d printing (like my example with Inkscape and J Tech laser cutter plugin).
But I believe that even our slicing programs are starting to introduce them, because of better performance on drip-fed systems (over USB or Network), smaller file sizes and better looking prints on round surfaces.

There is no high priority with this wish, it's just a "nice to have" feature, and seems that most other firmware already support it.
I found a work around for this issue: I can use G-Code-Ripper (a nice utility) to convert arcs to lines with selectable resolution. I still have to test it on the machine, but the Gcode file looks good after conversion.

Regards

Edited 1 time(s). Last edit at 07/21/2016 03:53AM by unromeo21.

I am glad you have a workaround. The reason that slicers don't generate arc moves is that the input files to them are generally STL files, which are incapable of describing curves. A slicer could only generate arc moves if it recognised that a slice through a sequence of facets described an arc of constant radius, and made the assumption that the user really wanted a smooth curve.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Slicing software can take obj and 3ds files as well. Are these also incompatible with arcs ? I have read somewhere that there was an option to preserve smooth arcs inside slicing software. Not sure if it's still up to date...

Also found this quite interesting

Edited 1 time(s). Last edit at 07/21/2016 04:44AM by unromeo21.

Quote
dc42
I am glad you have a workaround. The reason that slicers don't generate arc moves is that the input files to them are generally STL files, which are incapable of describing curves. A slicer could only generate arc moves if it recognised that a slice through a sequence of facets described an arc of constant radius, and made the assumption that the user really wanted a smooth curve.

Many cam programs do what's called "arc filtering" which fits an arc to a series of small line segments (typically speced with a chordal error tolerance). Smaller file sizes and less buffer starvation in the motion planner are two immediate benefits. I know that current slicers don't do this but imo they likely should.