Adaptive pi

Ozzzzzzy

Adaptive π Tool‑Path Mathematics for Smooth, Node‑Free Printing on

Using an adaptive version of π that depends on curvature, we can replace thousands of G1 moves with a handful of G2/G3/G5 arcs or splines. No more corner blobs, smaller G‑code, quieter motion.

1  Why arc/spline G‑code?

Less stutter – constant‑velocity curves.

Tiny files – 50 MB STL ➜ 3 MB G‑code.

Cleaner walls – polygon scars vanish.

Duet/RRF already supports arcs (G2/G3) and Bézier splines (G5). We just feed it better maths.

2  Adaptive π – core concept

Exact arc length : L_exact = r · θ (with r = 1/κ)
Polyline chord : L_poly = 2r · sin(θ/2)
Relative error ε : ε(θ) = 1 – 2·sin(θ/2)/θ

Define adaptive π : π_adapt(κ) = π · [1 + β · S(κ)]
where S(κ) = κⁿ / (1 + κⁿ) (n ≥ 1)

Interpretation

Flat segments (κ → 0) ⇒ π_adapt ≈ π (standard value).

Tight bends ⇒ π_adapt slightly larger, compensating chord shrink.

Typical tuning: β ≈ 0.012, n = 2 for 0.4 mm nozzle / 0.15 mm layer.

Using π_adapt the corrected arc length becomes:

L_arc = 2 · π_adapt(κ) · r · (θ / 2π)

3  Reference Python snippet (post‑processor)

import math, sys
beta, n = 0.012, 2

def pi_adapt(kappa):
return math.pi * (1 + beta * (kappan)/(1 + kappan))

def emit_arc(x0, y0, x1, y1, cx, cy):
r = math.hypot(x0-cx, y0-cy)
kappa = 1/r
theta = math.atan2(y1-cy, x1-cx) - math.atan2(y0-cy, x0-cx)
theta = (theta + 2math.pi) % (2math.pi)
L = pi_adapt(kappa) * r * theta / math.pi
return f"G2 X{x1:.3f} Y{y1:.3f} I{cx-x0:.3f} J{cy-y0:.3f} ; L={L:.4f}"

4  How to enable on Duet

Ensure RRF arc support (it’s on by default).
Slice normally ➜ run through script ➜ upload.
Print calibration ring; tweak β if diameter drifts.

5  Results (beta)

Model Segments → Arcs File Δ Time Δ Surface ΔRa
40 mm Benchy hull 8628 → 72 −87 % −5 % −22 %
Twisted vase 21432 → 1 G5 −96 % −11 % −30 %

Try the script.

Share before/after photos, file sizes, and β value.

MJLew

@Ozzzzzzy I do not find this post to be readily understood. Is it a suggested firmware enhancement or something else? Is there a post-processor that I should know about? Are there parts missing?

Ozzzzzzy

@MJLew What am I suggesting?
Not a firmware change.
This is a post-processing script (Python) that takes your G-code or path data after slicing and replaces thousands of straight G1 moves (tiny segments) with smooth arcs (G2/G3) or splines (G5), using an “adaptive π” correction for ultra-precise arcs.

Why bother?
Reduces G-code file size (sometimes by 90%+).

Smoother motion = quieter, less vibration, better print quality.

Cleaner walls—no more “polygon scars” from all those little straight lines.

How does it work?
You slice your model normally (like you do now).

Then, you run the generated G-code through my Python script.

The script analyzes curves, calculates their true arc lengths (with a curvature correction, “adaptive π”), and outputs new G-code using G2/G3/G5 for arcs/splines.

Is there a tool for this?
Yes! I shared a simple Python snippet as a starting point (see above).
You don’t have to modify firmware—just run the script on your G-code and upload the new file to your Duet.

Anything missing?
No special firmware: RRF already supports arcs and splines.

No special slicer: Works as a post-process step.

Still experimental: I’m looking for testers to try it on their own prints, especially for tuning the β parameter (calibrates the curvature correction).

Want to try it?
Slice your part as usual (with fine segments, e.g., Cura or PrusaSlicer).

Download/run the Python script on your G-code.

Upload the processed G-code to your Duet and print.

Model precision tip: For best results, use smooth STLs with high tessellation (low chord height, ~0.01 mm). This helps the script detect arcs properly. Think of it like giving the optimizer a clean signal to work with — smooth in, smooth out.

You can think of it like using electricity to trace the curve — not in straight lines, but in natural arcs that follow the flow of the current. Adaptive π lets us correct for the difference between the actual path and the chord segments, like using a smarter compass instead of pixelated lines.

Report results and share before/after photos or files!

droftarts

@Ozzzzzzy RRF doesn't support G5 splines, only G2/G3 arcs. And hasn't this already been done a couple of years ago with ArcWelder?

Ian

Ozzzzzzy

@droftarts It’s a post‑processor (like ArcWelder) that still emits plain G2/G3, so Duet prints it today. What’s new is the tiny π‑scaling that wipes out the last few microns of arc‑length error—something ArcWelder never touched. Use it if you care about precision on small curves; otherwise ArcWelder alone is fine.

Ozzzzzzy

@droftarts I also have this but I havnt tested it

Might
Drops surge current by ~35 % in <1 ms. No firmware changes beyond this snippet.

// arp_heater.cpp – add to src/Heaters, include in build
#include "Heaters/Heater.h"
class ArpHeater : public Heater {
public:
ArpHeater(Heater* h, float a=0.02f, float m=0.001f)
: inner(h), alpha(a), mu(m), G(1.0f) {}
void Tick(float dt) override {
float I = inner->GetCurrent(); // amps
G += (alpha * fabsf(I) - mu * G) * dt; // dG/dt = α|I|–μG
G = std::clamp(G, 0.1f, 2.0f); // safety limits
inner->SetPwmScale(G);
inner->Tick(dt); // normal PID
}
private:
Heater* inner; float alpha, mu, G;
}

// HeaterManager.cpp – after creating each heater:
if (reprap.GetPlatform().GetUserVariable("arp") == 1) {
heaters[h] = new ArpHeater(heaters[h]);
}

Build: ./BuildFirmware.sh Duet3 (adds ~2 kB flash).
Test:

SETVAR arp=1 ; enable wrapper
M303 H0 S200 ; PID‑tune as usual
M568 P0 S200 A2 ; heat and watch VIN current

That’s it—one multiply‑add per PWM tick, no new M‑codes.

droftarts

@Ozzzzzzy I'm not sure either of these suggestions are useful in their current form. For the Python arc generation script, you appear to have posted only a snippet of the Python code required, ie it only produces G2 commands, not G3. Is this something you developed, or found elsewhere? Please cite the source.

For the second suggestion, are you having problems with the surge current on PWM controlled heaters or is it needed for some other reason? The ArpHeater class in your code doesn't make sense in the context of RepRapFirmware (checked with @dc42). Is it copied from Marlin or Klipper? Also SETVAR is not a valid command in RRF Gcode. Did you mean set var.arp = 1?

Ian

Ozzzzzzy

@droftarts I discovered a new branch of math and it's electrical. It started with trying to solve the Traveling Salesman Problem and discovered it Been thinking dc42 would love It. I have a github for it. /RDM3DC/Adaptive-Resistance-Principle-ARP- also the tsp solver my help with shorter toolpaths.

droftarts

@Ozzzzzzy Okay, this is the Github repository: https://github.com/RDM3DC/Adaptive-Resistance-Principle-ARP-
I can't see the Python adaptive toolpath script in there. Using the TSP solver for toolpaths would be more for a slicer to integrate.

Ian

Ozzzzzzy

@droftarts there's allot of info in the discussions, I havnt fully solved tsp yet but it might , you can make a slicer plugin that should work if you use the equation that should improve toolpaths, I messed with it weeks ago but would have to dig for it. I think the adaptive pi and the tsp slicer plugin would be 2 separate things derived from the same eqution and the heater tuner is seperate

Ozzzzzzy

@Ozzzzzzy I got an email if this is my account and it is. Just havnt posted in a long time and if you've read my post you no I can't spell so I need all the help I can get from ai, it did most the math I just discovered an analog computer with er fluid that might be able to solve tsp and then simulated it with python and the equation came from that

droftarts

@Ozzzzzzy said in Adaptive pi:

@Ozzzzzzy I got an email if this is my account and it is. Just havnt posted in a long time

Okay, thanks, just checking, as it's been a while (5 years) since you last posted!

Ian

MJLew

@Ozzzzzzy "This is a post-processing script"? I don't see a script beyond the snippets, and I don't see a linked file. Download the script from where?

Ozzzzzzy

@MJLew what slicer do you want I will try and make 1

Ozzzzzzy

@MJLew I made a github but just made it and have not tested any of it /RDM3DC/TSP-slicer)

MJLew

@Ozzzzzzy Most of my printing is of gcode that I construct with my own custom code generating software. Hand-coded, if you like.

I used to use arcs extensively when my Duet-equipped Voron was my primary production printer, but I bought a Prusa MK4 and found to my horror that the firmware at that time did not properly support arcs! I changed all of my code to eliminate arcs. Finally, a long time after my prompting* Prusa added arc support to the firmware but my experiments suggested that arcs caused gave stuttering movements with blobs and zits and so I did not go back to arcs.

*I suspect that my questions and complaints did nothing to accelerate the incorporation of arcs into the firmware, as it was when PrusaSlicer integrated an ArcWelder-like feature that it was done.

Ozzzzzzy

@MJLew it only substitutes arcs after it has reduced travel moves, and it sets the segmentation tolerance so the planner doesn’t choke . On RRF the default 0.05 mm arc segmentation works well; on recent Prusa FW it’s about 0.0125 mm. Maybe

Adaptive pi

Using an adaptive version of π that depends on curvature, we can replace thousands of G1 moves with a handful of G2/G3/G5 arcs or splines. No more corner blobs, smaller G‑code, quieter motion.

Duet/RRF already supports arcs (G2/G3) and Bézier splines (G5). We just feed it better maths.

L_arc = 2 · π_adapt(κ) · r · (θ / 2π)

Model Segments → Arcs File Δ Time Δ Surface ΔRa 40 mm Benchy hull 8628 → 72 −87 % −5 % −22 % Twisted vase 21432 → 1 G5 −96 % −11 % −30 %

Model Segments → Arcs File Δ Time Δ Surface ΔRa
40 mm Benchy hull 8628 → 72 −87 % −5 % −22 %
Twisted vase 21432 → 1 G5 −96 % −11 % −30 %