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.

The original bearings are 6209 2RS and 6009 2RS; they don't have "C3" stamped on them, so they are likely CN (standard clearance). They are press-fitted without any additional clamping.

forum.linuxcnc.org/10-advanced-configura...oling?start=0#225787

forum.linuxcnc.org/show-your-stuff/53476...rical-mapping#307444

Any progress so far? I was wondering, if the mathematics in @nojo project is correct, would it be possible to create a hybrid solution by combining it with @fsabbatini project? Specifically, using the tool offset handling from @fsabbatini project and integrating it into @nojo project.

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.

Here is the file, you can see that  stepgen 03  has only dir , I don't understand why I put aside this combination: 7i80-7i85s-7i37 went 3 motors in step dir. I only need it as a transition because then I will switch to the 7i97t in analog, but for now I wanted to use step dir for 4 motors without any encoder or anything else.
in practice only the stepgen 3 one doesn't work 

Actually one way to do this would be to write a gcode filter for linuxCNC  that looked for hole below a certain diameter, removed the hole processing and replace it with a spot at the hole centre. Monokrom plasma has a filter that modifies hole processing so perhaps it can help you.

Another really out there possible solution that does not need post processing (but requires master branch) could  be to write a component or modify plasmac.comp and monitor the pin motion.interp.iscircle. When it goes true and motion.interp.arc-radius < minimum hole radius, disable the torch, use external offsets to move a distance of motion.interp.arc-radius along motion.interp.normal-heading (which will be your hole centre), fire the torch to spot, then unwind the offsets to return to where the torch was, let motion take over again then enable the torch when iscircle goes false.(the end of the hole)

I just noticed the hal tutorial is not obvious from the earlier link I shared. It is  here . Also explore the rest of the  manual .