Advanced Search

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.

My name is Santiago.
The email subject is: 'MESA ELECTRONICS - Argentina Shipping'.

I'm specifically looking for the 7i97T and 7i84U boards.

Not me, but i have a friend that i advised on using Claude for website coding, he swears by it as it was extremely useful to him...after the initial rage.
I would guess it should do a decent job at it for QT stuff as there is more info on the net it can search through, but i would try something different...

Hi Hakan,
just a quick follow-up to my previous reply: I can confirm that extending the LCEC driver to expose the drive’s internal following error works fine with the Delta ASDA-B3 drives.I mapped 0x60F4 (Following error actual value) into the TxPDO and added it as a HAL pin (including scaling to mm). This gives a much more reliable “real” tracking error compared to the LinuxCNC ferror which is affected by the EtherCAT timing delay.For reference:
I patched the LCEC driver , rebuilt linuxcnc-ethercat and had everything working within a couple of minutes. Two additional pins are now available: srv-ferror-raw and srv-ferror (scaled to machine units).

You can also make your own following error check routine in LinuxCNC (HAL-side).
It could even be a more intelligent solution, for example reducing speed/feed when the error becomes significant, instead of immediately throwing a fault.

For anyone who wants to implement this: just clone the linuxcnc-ethercat repo, replace the file in the, build and install it (

@ grandixximo ,
Thank you for the immense amount of time and effort you and your team are putting into this.
Side note, should i contact Grotius by phone and see if he can spare some time, or should i wait for now?

Has anyone tried ai services(claude/chatgpt/gemini) for developing custom user interfaces ?
I have tried ai for gcode generation and the results was almost perfect..

Hakan wrote:

And my brain hurts. 

That, i believe!
Thank you for the detailed explanation.

forum.linuxcnc.org/18-computer/54369-use...hernet-boards#313956
forum.linuxcnc.org/18-computer/54369-use...hernet-boards#313961

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!