Does RRF support 3d arcs?

markz

Simple question - I'm trying to carve some fairly intricate stuff and noticed that the Fusion360 postprocessor I'm using switches off 3d arcs for Reprap. Is this old and does, by any chance, RRF 3.x support 3d arcs?

Thanks.

oliof

@markz G2 and G3 commands are supported in RepRapFirmware.

rjenkinsgb

@oliof said in Does RRF support 3d arcs?:

G2 and G3 commands are supported in RepRapFirmware.

I believe the OP means helical interpolation, moving on all three axes?

I've found a reference to that on here from a few years ago, which implies helical is supported:

https://forum.duet3d.com/topic/1662/running-gcode-cnc-on-duet-wifi/25

From the current gcode list, G17/18/19 plane selection is also supported now.

https://duet3d.dozuki.com/Wiki/Gcode#Section_G17_Select_XY_plane_for_arc_moves

alankilian

@rjenkinsgb I can verify that G2 and G3 with x y z i j work perfectly.

markz

@alankilian @rjenkinsgb Thank you both very much. Sweet, I'll upgrade my postprocessor.

bot

Let's get some cubic splines now!

https://marlinfw.org/docs/gcode/G005.html

dc42

@bot said in Does RRF support 3d arcs?:

Let's get some cubic splines now!

Does any slicer actually generate them?

bot

@dc42 Not that I am aware of. Fusion 360 should be able to, but it does not afaik.

By the year 2030 at the latest, I plan to have PrusaSlicer slicing STEP files directly, and outputting fitted bezier curves for all perimeters (that are not perfectly straight nor simple arcs).

So, no rush.

ÖrjanE

From what I have understood, the tricky thing to get right when extruding along Bézier curves is the filament extrusion rate. The G5-command, as it is defined in Marlin, gets the total amount of extrusion for the curve, but to calculate the extrusion rate you also need the length of the curve. The problem is that there, apparently, exists no closed formula for the curve length. The length can be estimated numerically by simulating the move, but this is hard to realize in real time; you can not start the move without knowing the entire curve length.

I have not looked into the Marlin source code recently, so I do not know how they solve this.

bot

@örjane This, among other difficulties, is why the ETA has been pushed to 2030.

Also, offsetting bezier curves is non-trivial, e.g., for the inner perimeters (and the outer perimeter, too, because it must be offset in by half an extrusion width).

I spoke with merill of SuperSlicer once about it, and we agreed that forcing approximations of the correct bezier curve to fit highly-detailed faceted polylines would be the easy/perhaps best approach. Thus, we could steal the length from that prototype high-resolution polyline.

Currently, the mesh limits the polyline resultion. If no mesh were limiting the resolution, then the douglas-peucker algorithm limits the polyline resolution.

We can generate an overly-high-resolution polyline to fit bezier curves to. Basically, the slicing would work as it does now, but using STEP files as input and discretizing the polylines to very high detail. The perimeters would be offset like normal. It is only after we have the properly offset segmented polylines for all perimeters that we then generate and force to fit approximations of the required bezier curve -- they would technically not be the identical to-the-micron bezier curve that the STEP model has on its outer surface, but it would be close.

The purpose of the bezier curves is not to get higher resolution curves: we can already max out the resolution of the mesh and get smooth-as-silk curves.

Instead, the point of bezier curves is to print those smooth curves fast, because hopefully the throughput of processing those splines would be faster than the many g-code moves required to define a high resolution sequence of G1 moves.

ÖrjanE

@bot I looked briefly into the Marlin source code for G5 and, as expected, they do not solve the problem with extrusion rate. They seem to use the t-parameter (that runs from zero to one along a Bézier curve) to linearly control extrusion. That code is actually marked with a "FIXME" comment. For simple arc-like curves, this may be good enough, but for wilder Bézier curves the extrusion rate will vary considerably along the curve.

Since the slicer does not have to work in real time, and, as you say, often already has the curve represented as line segments, it would be good if the slicer had some way of telling the firmware what the curve length is. One obvious solution would be to have the curve length as an extra parameter to G5.

bot

That is interesting info thank you for looking at the marlin source.

One thing I forgot to mention: when merill and I were discussing it, we realized that the beziers would have to be chopped up arbitrarily. As in, there might be multiple fitted "close enough" bezier curves for what would ideally be a single curve. This is because the offset of a bezier curve can, I think, never (or maybe just not always) be represented by a slightly different single curve.

I forget the specifics, I may be misremembering, but the information seemed to be somewhat common knowledge when I was googling it a year or so ago.

MikeS

@bot You might be interested spending 30 minutes watching this: https://youtu.be/aVwxzDHniEw . I enjoyed it a lot!

markz

Well, that came out just great - smooth and all the detail showed up. Thanks. For scale the nearer lizard is about 1.5" long.

alankilian

@markz

That looks awesome!

oliof

This post is deleted!

markz

@alankilian Thanks. The finish is really glossy so it shows the machining ripples well in this light and they're just spot on.

seeul8er

I wrote an experimental slicing script for doing parametric slicing. Computing the offset curves is too hard in my opinion. Instead you should only make the outer perimeter a parametric curve and discretize the inner extrusions as usual.

The framework i use for slicing will also output bezier curves (converted from bsplines) that are of degree 5 etc. As I see it Marlin/GCode Standard only supports degree 2/3 which is quadric/cubic. This means you would need support for higher degree curves as well.

So the best way I currently see is doing some sort of curve fitting inside the slicer or the Duet. Maybe even assisted based on a parametric slice. Modern CNCs can already do this kind of fitting. I think I read something about it on a Siemens control unit.

dc42

@seeul8er perhaps implementing bsplines in RRF would be a better way forward than implementing bezier curves?

ÖrjanE

@dc42 I'm not sure, but I do not think B-splines would be easier to implement or use.

From what I understand, there are two problems with Bézier curves in this context:

The length of the curve is unknown beforehand.
Drawing with an offset from a Bézier curve is not itself following a Bézier curve.

The first causes problems to compute the extrusion rate if only the total extrusion is known. The second causes problems when drawing multiple walls or when the outside of an object should follow a Bézier curve.

Both these things can be avoided by defining the G-code somewhat differently from how Marlin has done it. If the extrusion rate (mm filament per mm movement) is given as a parameter, instead of the extrusion length, this would solve the first issue. The second could be handled by an optional offset parameter to move the tool with an offset (along the normal) to the curve. Both these things would be fairly straightforward to implement (I think...), and potentially useful for a slicer.

Does RRF support 3d arcs?

Robert J.