LinuxCNC S-Curve Accelerations

This is a draft for a new TP implementation plan, revised according to my thinking by AI

---

## LinuxCNC S-Curve Trajectory Planner Rewrite

### Architecture Principles

**RT thread (250µs capable):** Only evaluates pre-computed polynomials. No planning, no Ruckig, no kinematics. Just `position = evaluate_polynomial(t)` and send to drives.

**Userspace:** All heavy computation. Ruckig, backward velocity pass, kinematics, blending. Not tied to servo cycle.

**Predictive Handoff:** When replanning is needed (feed override, etc), userspace plans from a predicted future state, not current state. RT continues executing until the handoff time, then seamlessly transitions. This decouples userspace latency from RT determinism.

**Buffer Management:** Track buffer in TIME, not segment count. Short segments and long segments treated appropriately.

---

### Phase 0: Foundation - Port Tormach 9D Architecture

```
├── 0.1 Port dual-layer architecture (userspace planning / RT execution)
├── 0.2 Port atomic state sharing between layers
├── 0.3 Port 9D vector abstractions
├── 0.4 Port lock-free segment queue
├── 0.5 Port lookahead buffer
├── 0.6 Port backward velocity pass (computeLimitingVelocities)
├── 0.7 Verify trapezoidal works through new architecture
├── 0.8 Verify E-stop works
└── 0.9 Test: motion runs, velocity anticipates corners
```

Meeting with Robert Ellenberg on the 28th should clarify what's clean to port vs what needs adaptation.

---

### Phase 1: Move Kinematics to Userspace

```
├── 1.1 Userspace samples path, computes Jacobian
├── 1.2 Joint limit pre-calculation (YangYang)
├── 1.3 Joint limits fed into backward velocity pass
├── 1.4 RT receives joint-space polynomial segments
├── 1.5 Test on non-trivial kinematics (5-axis, etc)
└── 1.6 Verify E-stop works
```

This is the risky phase. State consistency between userspace and RT must be bulletproof.

---

### Phase 2: Ruckig Integration

```
├── 2.1 Add Ruckig to build system
├── 2.2 Backward pass computes v_entry, v_exit per segment
├── 2.3 Forward pass: Ruckig solves each segment with entry/exit constraints
├── 2.4 Output: joint-space polynomials to RT queue
├── 2.5 Scrap sp_scurve.c (current S-curve implementation)
├── 2.6 Test: globally optimal jerk-limited velocity profiles
└── 2.7 Verify E-stop works
```

Ruckig runs in userspace only. Takes ~1ms per solve. RT never waits for it.

---

### Phase 3: Predictive Handoff System

```
├── 3.1 RT continuously publishes execution state (segment ID, time within segment)
├── 3.2 Define buffer time parameters in INI:
│ MIN_BUFFER_TIME_MS = 100 (RT warns if below)
│ TARGET_BUFFER_TIME_MS = 200 (userspace maintains this)
│ MAX_BUFFER_TIME_MS = 500 (userspace pauses if above)
├── 3.3 Define HANDOFF_HORIZON_MS = 50 (how far ahead to plan handoff point)
├── 3.4 Implement TIME-based buffer level tracking
├── 3.5 Adaptive throttling: userspace speeds up if buffer runs thin
├── 3.6 Predictive handoff flow:
│ a) Feed override changes (or other replan trigger)
│ b) Userspace picks T_handoff = now + HANDOFF_HORIZON
│ c) Userspace evaluates current trajectory at T_handoff to get predicted state
│ d) Ruckig plans from predicted state to target with new constraints
│ e) New segments tagged with handoff time, pushed to queue
│ f) RT executes old trajectory until T_handoff, then switches seamlessly
├── 3.7 Test: rapid feed override changes, verify smooth transitions
├── 3.8 Test: userspace delays (artificial), verify RT never starves
└── 3.9 Verify E-stop works
```

Key insight: 100ms feed override latency is invisible to humans. RT starvation is catastrophic. Plan ahead, never make RT wait.

---

### Phase 4: Blending

```
├── 4.1 Blend geometry using Beziers (not arcs)
│ - Works naturally in 9D (arcs are fundamentally 2D)
│ - Faster to evaluate (polynomial vs sin/cos)
│ - Smoother curvature transitions (no curvature discontinuity at entry/exit)
│ - Steadier velocity through corners
├── 4.2 Blend size respects G64 P tolerance (same contract as current LinuxCNC)
├── 4.3 Blend velocity limits feed into backward pass
├── 4.4 Ruckig solves blend segments
├── 4.5 Test: continuous cutting, no velocity bobbing through corners
└── 4.6 Verify E-stop works
```

---

### Phase 5: Hardening

```
├── 5.1 Test with artificial userspace delays (verify RT never blocks)
├── 5.2 Test at 250µs servo period
├── 5.3 Singularity handling (automatic slowdown near singularities, no faults)
├── 5.4 Edge cases: very short segments, reversals, exact stop (G61)
├── 5.5 Spindle sync moves (rigid tap, threading) - automatic fallback to trapezoidal
├── 5.6 Probe moves - automatic fallback to trapezoidal
├── 5.7 HAL pin for manual planner_type selection (user can force trapezoidal via M-code)
├── 5.8 Stress test: worst case G-code with rapid feed override changes
└── 5.9 Final E-stop verification under all conditions
```

Trapezoidal fallback stays for special cases. Some operations need tight timing that S-curve planning would compromise.

---

### Phase 6: Cleanup

```
├── 6.1 Remove dead code from tp.c (old S-curve paths)
├── 6.2 Remove sp_scurve.c, sp_scurve.h entirely
├── 6.3 Update HAL pins:
│ - jerk-cmd outputs
│ - planner status
│ - buffer level (time remaining)
│ - handoff state
├── 6.4 Update documentation
├── 6.5 INI file changes:
│ - JERK_LIMIT per axis
│ - MIN_BUFFER_TIME_MS
│ - TARGET_BUFFER_TIME_MS
│ - MAX_BUFFER_TIME_MS
│ - HANDOFF_HORIZON_MS
│ - Deprecate old parameters
└── 6.6 Backward compatibility: PLANNER_TYPE=0 still works (pure trapezoidal)
```

---

### Summary of Key Design Decisions

| Decision | Rationale |
|

---

|

---

|
| RT only evaluates polynomials | 250µs determinism, no jitter |
| Ruckig in userspace only | Heavy math stays out of RT |
| Predictive Handoff | Decouples userspace latency from RT timing |
| TIME-based buffer | Handles short and long segments correctly |
| Beziers for blending | 9D native, faster, smoother than arcs |
| Trapezoidal fallback | Threading, tapping, probing need it |
| E-stop verified every phase | Can't wait until the end |

Any feedback will be considered, and appreciated, this is obviously a plan far from being set in stone, just a wild idea at the moment...

Sure, we're glad to get all the help we can get, this is just in the idea phase for now, so even just useful input would be nice, YangYang is not on board yet, it is just my idea at the moment, but I am not forcing it down anyone's throat, this has to be scrutinized by who understands more than me, or have different point of view on things, Grotius YangYang Robert ihavenofish, really I welcome all input, it should not be a fight, the correct solution I hope will arise from the collective experience of the community, and who is willing to share it, for the benefit of all.

interesting discussion.
I am of the opinion that the limits of jerk, acceleration and speed should always be adhered to (load on the mechanics...).
If I want a higher or even speed, I have to design the milling path in such a way that a higher or even speed is achieved while taking into account the limits of jerk and acceleration (G64 Pxx, G64.1 for ...).
Inadequacies in the milling path should not be compensated for by violations of the limits of jerk and acceleration.

I would like the discussion to go more towards improving the S-Cutve

@Vegko
I changed your NC code a little (corner radius 0)

grandixximo wrote:

@Aciera
Yes, I think Robert and YangYang will have much to discuss. I will probably mostly be on the sidelines, help YangYang with the English mostly, I think he'll do better than he thinks.

@ihavenofish
spikes you see on the scope are ddt of ddt of ddt, planner_type 1 has been running on real machines, it is not as expetimental as you might think, far from perfect I can agree, I can understand that you don't want to put your hardware on the line.
Not to worry about, I have hardware, you can see at www.aitalmac.com
Anyhow thank you for your inputs, have give me lots to think about!

Videos of it running on a stone bridge saw please!

We all want to see pretty moving pictures. mmmm.


 

You can find more on the youtube channel

grandixximo wrote:

You can find more on the youtube channel

Oooh. So this machine runs linuxcnc with jerk limiting?
 

Yes, most machines you see on the website do, the one I have most problems with is the sawjets, because of the huge kinematics pivot.
The only issue I found that needs fixing with the latest code, is when I do codes to mill down the table, zigzag style, YangYang will take a look next week, he keeps patching that up. And then it comes back again...

 

Inadequacies in the milling path should not be compensated for by violations of the limits of jerk and acceleration 

It is not the case that we try to fix inadequacy of the path by spiking the jerk, is that we cannot control the jerk spikes period. This is not because we don't want to or lack of trying, is IMO fundamentally a limitations of the current tp architecture. YangYang is trying work arounds...

Hey guys have a look at the link to the YouTube channel

These guys have a whole factory running linuxcnc I think.

Is awesome.

I have 7 machines here in NZ but these guys have way more stuff for testing.

Grandixximo.

Can you take some more videos of your machines please
Even a non promotional video for us linuxcnc guys where you can really dig into how your have implemented it.

This is perfect for testing 5 axis stuff and your jerk control.

And I just want to say thanks for trying to help the open source community.


Not everyone does that.

Cheers