Advanced Search

Do abefore trying to install something, then

Well, I think it follows the state diagram up to the point of operation
 

But for sure it isn't perfect. I have noticed multiple homing components around even if I don't use it myself.
Can you add support for PV (Profile Velocity) while you are at it? I made a quick fix for that.
PV is suitable for spindle mode.

You should be able to transition states manually, in halshow for example, using controlword and check statusword.
Maybe that can give a clue to why it seems so grumpy.

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

Not to worry about, I have hardware,

Oo, no kidding. Not much use for a giveaway CNC mill there.

yeh, I looked at dmesg.
I did a brief review. It looks like cia402 is getting an enable signal and something goes awry before the drives come on line
I've never liked the current cia402 component source code as its really too hard to debug and does not follow a cia402 state machine.
It also no longer works properly for homing without modification with the advent of homecomps!
So I'm going to try to rewrite it 

I agree with Aciera. Rob will have a lot of good and implementable suggestion and cooperating with him to get the planner out would be a good way forward.

On the topic of path modification v/s jerk limitation, you cannot think about one as separate from the other.
Imagine a path that has lines and tangent arcs i.e., a straight line in Y axis followed by an arc in the XY plane. Right before the transition point, the velocity and acceleration in the X Axis are 0. At the transition point, you can assume the velocity on the X axis will start increasing in a sinusoidal fashion from 0 whereas the acceleration will start at a high value. So even if the velocity is continuous, the acceleration can not be made continuous which will lead to a high jerk due to the acceleration discontinuity.

To remedy the acceleration discontinuity, one method is to come to a full stop at the transition. Another method is to add a transition i.e., modify the path between the two segments which is C2 continuous (second derivative continuous) at both the ends where it intersects the segments. Examples are clothoids, beziers, splines etc. as proposed by multiple research articles on this topic.

The grotius clothoid solution is one step in the right direction. IT will require to add a new geometry to the the motion queue called clothoid in addition to addline and addarc functions that are already being used. Clothoids and some splines are parameterizable by their path length and so can be used much easier in trajectory planning.

In essence, the tanjential jerk (to the path) can be managed by changing the trajectory execution timing parameter whereas the normal jerk can be reduced by changing the path (including a small deviation).

-automata

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

I'm glad you at least appreciate the dilemma

@grandixximo
If Rob Ellenberg is offering advice/cooperation I would not hesitate to accept it. Having written the current planner you'll likely get more sound information (and even opinion) )there in one email than on 40 pages of forum thread. Grotius flatly refused which was a great mistake but I think our clothoid approach was likely doomed to fail anyway.

Hi Hakan,

thank you very much for the detailed explanation - it was extremely helpful. It’s absolutely clear to me now how the timing works (lcec.read-all / lcec.write-all, the Sync0-based PDO exchange, and why the position feedback seen by LinuxCNC is inherently delayed by a couple of servo cycles).

Also, thanks a lot for the sketch/diagram … that made the whole sequence much easier to understand.

I’ll now check whether my delta drives provide a real internal following error / tracking error value as a PDO, and if so, I’ll try to map it into LinuxCNC.

Thanks again for taking the time to explain it so thoroughly.

Aciera wrote:

Too much navel gazing. where are the machines? where are the beautiful surface finishes? where are the accurate parts and their measurements? That's what most of us want to see.


Maybe the community and the people so eager to have these features could donate some of their time to test and provide feedback? 3000$ is nice but it is not going to be much compensation (even if it were in cash) for donating all the work required here.

This is tricky. A dev should have hardware on hand which I know is hard, but there's also no way I'm installing anything on my machine to test that I don't know already works 100%. A crash at full speed can cause thousands of dollars in damage (ask me how I know).

Double edged catch 22. I appreciate the dilemma.

(side diversion I added g64 beziers to my vibe coded planner. First approximated ones which caused accel violations, and then real ones which seem to work right. I will make a new thread for it to not clog this one up. The source might be helpful to the people coding the "real" one, not sure)



 

Too much navel gazing. where are the machines? where are the beautiful surface finishes? where are the accurate parts and their measurements? That's what most of us want to see.

Maybe the community and the people so eager to have these features could donate some of their time to test and provide feedback? 3000$ is nice but it is not going to be much compensation (even if it were in cash) for donating all the work required here.

grandixximo wrote:

@ihavenofish I think there's some confusion here worth clearing up, you're right that filtering (like Tormach does) gives you unpredictable deviation, the path ends up wherever the filters spits out, that's not what we're after.

But I think you're mixing up two different things, how the machine speeds up and slows down is jerk control, whether we cut corners is G61 vs G64, these are separate knobs, if you want perfect path following, use G61, the machine will stop at every corner, follow the exact line, no deviation, with proper S-curve planning it'll do that smoothly instead of jerking around, you get accuracy, you give up speed, fair trade.

G64 P is for when you say "I'm okay with cutting corners by up to this much, just keep moving." That's already how LinuxCNC works today, S-curve doesn't change that, it just makes the motion smoother while respecting whatever tolerance you set.

Why Beziers instead of arcs for blending?
Arcs are a 2D thing. Works fine for XYZ, but what's an "arc" when you've got 9 axes moving at once? It doesn't really make sense.
Beziers are just smooth curves that work in any number of dimensions.Also arcs have constant curvature, so when you enter and exit a blend there's a sudden curvature change, the TP deals with this by speeding up and slowing down, which is why you see velocity bobbing up and down through corners, Beziers can match curvature at the transitions, so you get steadier speed through the blend, And on top of that, arcs need sin/cos every servo cycle while Beziers are just a handful of multiplies and adds, In a tight loop running 1kHz+, that matters. Same tolerance as before, just a better curve to fill it with.

This isn't like the clothoid thing, we're not trying to get fancy with exotic geometry, just trying to get smooth motion that respects whatever path constraints you set, does that make more sense?

Just to be clear, the only reason I'm talking about deviation is because S-curve has to work in all modes, including G64 P where the user has asked for corner blending, s-curve isn't only for G61 exact stop, and there will always be a fallback to trapezoidal via HAL pins, some operations like threading, tapping, and probing need the tighter timing that trapezoidal gives you. You can hook planner_type to an M-code and switch modes in your G-code when needed.
 

I think that user should take in mind and just select active motion strategy by type of job ... tapping and threading is great to hase at rigid solid trapeziodal thingy ... but probing from my point of view has to be done outside of servo-thread at hardware layer of servo FPGA to get exact position .. no time or cycle lagging present 

change in CCS can affect mainly finishing turning paths and there it should be correct by postprocesor itself or user ... during slow finish use trapeziodal or 2. option (solved by hal layer)

filltering as simulations of jerk limiting at servo layer is highway to hell ... during the finishing paths mainly at turning there you will need to increase regulator parameters from the controller to servo driver rather you can forgot at product tolerances 

thing must be solved step by step .. phase 1. is really big deal for everybody .. roughing with high speed and low jerk with more laggy tolerance during high mass movement is better ... some jerk during finishing with clear smooth finish at low speed is acceptable for all ... we have regulators for that

I think re-editing the stuff which was coded in oposite of common avaible tp is not a right way ... there we are facing of problem a shiny new stp.c

Some ideas.
Check syslog: "sudo dmesg | tail -30"
Are pdos configurable? Check the esi/xml file. Adjust configPdos if needed.
It's one slave. Config looks ok in principle.
Try with only the seconds drive, remove 0x1600, 0x1620, 0x1630, same for Rxpdos.

Another possible scenario to consider might be

- Velocity planner with jerk limitation for G61 (exact stop)
- Velocity planner without jerk limitation for G64 but with bezier path blending

Although I'm not clear on how much easier bezier path blending becomes without the jerk limited velocity planning.

At the end of the day it is clearly up to the people donating their time to decide what they want to achieve.

this is a bit tricky because you need non-free in your sources. This is included in our ISO
skip geub-customizer for now