LinuxCNC S-Curve Accelerations

github.com/grandixximo/linuxcnc/tree/9d

This is phase 0 completed, according to my plan, this is extremely experimental work in progress, there are known issues at the moment, no arcs no blends, no scurve, as illustrated by the plan you can find at this post, which I got not much feedback..

forum.linuxcnc.org/38-general-linuxcnc-q...ons?start=640#341856

Next phase it is IMO too hard to be vibe coded, but I will try in my spare time.

I'll try to have a look at the '9D' branch later. Thanks.

which I got not much feedback..

Just as a word of caution from my own experience:
You mustn't expect to much from a forum thread like this. Few people will even read a post that long, fewer still look at the code and hardly anybody will even try to understand it. I know of at least one long time contributor, since retired, who got quite bitter about trying to get sustained and involved feedback here. Even from the very people asking for the specific feature.

I notice that you mention the use of 'ruckig', is this a decision you made or is that something AI suggested?
According to this statement (which I have not verified )the 'ruckig' library is not free for more advanced uses. (Not that this must necessarily be a deal breaker):
forum.linuxcnc.org/38-general-linuxcnc-q...nner?start=70#320906

[edit]
there seems to be a ''community" and a "pro" version of ruckig:
docs.ruckig.com/md_pages_2__intermediate__waypoints.html

There seems to be little information about the 'pro' version:
github.com/pantor/ruckig/issues/78

I'm a bit weary of anything that comes out of AI.
Could you give a bit more background information as to how you came up with these outlines? In other words: Are these the result of conscious deliberation or is that a product of AI?

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

Ruckig, I think we just need the math based on the math paper I think. Don't actually need to build the thing inside linuxcnc.
I proposed a minimum of 250us because that's what other users here expressed, otherwise you could run ruckig in the servo, but I thought better keep it out, even if advertised as 50us, some calculations seems known to exceed this advertisement. The handoff was my concept idea. Inspired by how CPU have predictive branching

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and help shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576