LinuxCNC S-Curve Accelerations

Look for my motion.interp.* pins for tangential knives etc too
If you follow the docs, a RIP build is super easy now.

hi grandixximo,
what is the progress of adding this liscio type of curve smoothing to linuxcnc master.
-automata

@automata
See github.com/LinuxCNC/linuxcnc/blob/master...xis_9axis_scurve.ini

I'd like to thank everyone who contributed to making this project a reality. Fantastic work! The difference with the new S-curve planner enabled is huge. Motion is noticeably smoother, and the overall machine behavior has improved significantly.

grandixximo wrote:

github.com/mika4128/liscio/tree/main
new trajectory/gcode compressor for the future trajectory planner, testers wanted, feed your gcode to it, check the SVG output
 
Hi grandixximo and mika4128 (Yang Yang),
Curve smoothing is the correct and best way to tackle Jerk that is normal to the motion path. This is reflected in the curve smoothing features from the large CNC controller brands referenced in the Liscio documentation.
I put the liscio library through an AI based analysis for integration into linuxcnc.
This is the analysis it has come up with.

Let me know how we can progress on this topic and the eventual jerk limitation implementation.

-automata

 

Library facts (verified in source, not the README):
- 6 `.c` files + 1 internal header + 1 public header; MIT licensed, single author (Yang Yang
  `mika-net@outlook.com` — the same upstream author as the already-vendored `cruckig`).

- Exactly one `calloc` (create) and one `free` (destroy); zero allocation afterward. No printf/assert/
  globals in library paths. Context is ~148 KB (91% of it a 64-slot arc-merge buffer); fitter stack
  worst case ~25–30 KB (bounded recursion, depth .

- `liscio_pose_t` is layout-identical to `EmcPose` — nine consecutive doubles x,y,z,a,b,c,u,v,w
  ([emcpos.h:19-23](../src/emc/nml_intf/emcpos.h), liscio.h:44-50). Add a `static_assert(sizeof)` in the
  adapter as cheap insurance.

- Emit is a synchronous callback invoked inside `add_*`/`flush` calls.### Known library defects and gaps (must be addressed before starting integration)| # | Defect | Evidence (liscio clone) |
|---|---|---|
| L1 | `liscio_reset()` does not clear `arc_buf_n` — arcs buffered before an abort are emitted into the **next program** | src/liscio.c:1437-1444 |

| L2 | No runtime tolerance setter — cfg is copied at `liscio_create`; G64 P/Q changes mid-program have no cheap path | src/liscio.c:108-131, liscio.h:285-309 |

| L3 | XYZ-collinear LINE fast path skips the ABC/UVW linearity gate — interior rotary nonlinearity silently discarded | src/liscio.c:540-561 |

| L4 | No `isnan`/`isfinite` anywhere; tolerance gates are `if (dev > tol)` so **NaN passes** | grep of src/ |

| L5 | F-word changes are absorbed silently (first-F-wins, plus an off-by-one via the flush reseed) | src/liscio.c:669-676, 1302-1311 |

| L6 | `liscio_emit_stop(pos=NULL)` emits zero poses despite header docs claiming last-known-position | src/liscio.c:1402-1407 vs liscio.h:363-367 |

| L7 | `liscio_add_arc` validates nothing (unit normal, radius/center consistency, type field) — caller trust | src/liscio.c:1181-1239 |

| L8 | Corner/discontinuity detection is XYZ-only — pure-rotary reversals never split the window | src/liscio.c:687-709, 736-752 |

| L9 | Struct doc mentions a `turn` field that does not exist (direction+wrap live in signed `arc_angle`) | liscio.h:98-105 |

| L10 | Independent verifier (`test_verify`) and fuzzer are XYZ-only / add_line-only — 9D fidelity is not regression-gated upstream | test/test_verify.c:53-62, test/test_fuzz.c |

L1 and L3 are correctness bugs; L2 is a hard integration blocker; the rest are adapter obligations.

Looks like you guys have been busy, this is awesome.

I decided to test out the capabilities of GPT 5.6 Sol by making an entire jerk-limited CNC controller from scratch over the last few weeks. It's mostly done and works, but I'm sure there are still bugs and things I need to finish. I have it working with my mesa 7i96, but haven't connected it all back up to my router yet. It "supports" 6 axes, but I have not even started to worry about the ABC axes yet as I have none on my router. github.com/a-downing/ngc .

The jerk-limited path solver is a small part of it and I ended up separating it out into its own repo here:  github.com/a-downing/PathTempo . It basically takes in a series of path pieces represented by a curve length and an array of samples of three derivatives (tangent, curvature, curvature-derivative) along that curve for the solver to use. The output is a sequence of time domain cubic polynomials representing cumulative distance along the path, with each polynomial belonging to one path piece. It has helpers to convert lines, arcs, helical arcs, and b-splines into path pieces with their curvature samples.

It has two modes, zero and optimized. In zero mode the acceleration between each path piece is zero, and in optimized mode it can be non-zero for a more time optimal trajectory. The zero mode is very fast (about 0.15% of trajectory time), and optimized mode has taken at most about 1.5% of the time of the trajectories that I've tested so far.

The trajectory planner supplies the real-time backend with timed axis-space polynomial execution spans, quintic for normal continuous motion and cubic for exact stop motion and stop-tails. Each motion chunk includes a proven stop-tail so the backend can stop safely if it reaches the chunk’s branch point without a valid continuation. Homing and probing is done in the backend. Feed hold is done in the backend and only enforces the feed-hold specific tangential jerk limit, and the tangential/normal path acceleration limit. I have not implemented feed override yet, this can be done entirely in the backend if you only allow lowering the feed rate, but for raising it you need to implement it in the planner, and the latency can be up to one planning horizon plus whatever motion the backend has buffered. To have an acceptably low latency the planner would have to only publish a certain amount of motion (measured in time) to the backend. This is doable, but it increases the chance that the backend has to take a stop-tail if something unexpectedly makes planning take longer.

G64 path smoothing is what needs the most work. The time-optimality is more sensitive to the path geometry than anything else by a large margin. A path that to the eye looks extremely smooth can have large curvature derivatives that harshly limit the maximum velocity through them to meet the jerk limit. What I'm basically doing is for lines and arcs above a certain size I join them with a curvature continuous cubic b-spline (not taking full advantage of the G64 P value yet). For spans of arcs/lines that are "small", control points of a quintic b-spline are dropped on their center points and the ends are joined to the enclosing "large" lines/arcs with curvature continuity. If you only do this it will look very smooth, but have large curvature derivatives that severely limit the max velocity. You have you run the spline through a smoothing algorithm that balances minimizing curvature and curvature derivative, while staying within the G64 P value from the original entities. It's already doing this, but I think it could be improved. It should also probably be removing control points in most cases, which it is not.

The one thing I've had no problem with yet is performance. The planner is able to produce work for the backend much, much faster than the backend can consume it. I think it is mostly because GPT 5.6 was able to come up with a very efficient jerk limiting solver, and that the work is pipelined with multiple threads. The first thread evaluates the gcode and produces path geometry and publishes it to a lock free queue, this work only has to be done once, but it takes the most time. Mostly because of the spline smoothing. The trajectory planner reads from this queue and plans a window that includes a stop-tail. Because of the stop-tail some of the same geometry is involved in the next planning window. The planner then publishes the axis space time domain polynomials to another lock free queue in the real-time backend.

I'm not sure if you guys will find any of this useful for the jerk-limiting in LinuxCNC, but I figured I'd drop this here.

Hi all,
Attached please find a pdf describing the math for the proposed jerk limited planner to be added. It is done by AI, and I want to put it up for community comments.  
I would be happy to discuss the approach and incorporate suggestions and make modifications to this plan as the discussion evolves.
-automata

I got this error. I reduced the acceleration slightly, and after that I produced 20 parts without any errors. Today the same error appeared again. I then restarted the same program, and so far there have been no errors.

 

on another part I get this error
 
ps:

I reduced the maxj quite a bit, but there is no change. I think it is related to the synchronized movement of the spindle.
 
 

Have patch waiting to merge to silence those.

We have been stuck on the feed override for TP2, doing it proper without any jerk spikes, is proving much harder than we thought.

Hi grandixximo,
We really appreciate your dedication to solve the jerk limiting trajectory planner issue.
Can you share the update on any git repo to get wider community feedback started?
Looking for to testing the new fixes.

-automata