@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

@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

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

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

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

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

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

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

1. Ensure RRF arc support (it’s on by default).

2. Slice normally ➜ run through script ➜ upload.

3. 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.