Simply over-write the LinuxCNC tp folder with the Tormach one

[andypugh]

This is just an exercise to see what changed. It definitely should not be merged.

[Sigma1912]

I have merged this into master on my fork.
Not sure if I am doing something obviously wrong but trying to compile I get a LOT of errors like this:

dave@EliteBook-840:~/git/mylinuxcnc/src$ make
Reading 204/204 dependency files
Done reading dependencies
Reading 274/275 realtime dependency files
Done reading realtime dependencies
make: Entering directory '/home/dave/git/mylinuxcnc/src'
cp ../scripts/rtapi.conf ../tests/uspace/spawnv-root/rtapi.conf
Compiling libnml/cms/cms_pm.cc
libnml/cms/cms_pm.cc: In member function ‘CMS_STATUS CMS::update(PM_CARTESIAN&)’:
libnml/cms/cms_pm.cc:21:12: error: invalid use of incomplete type ‘struct PM_CARTESIAN’
   21 |     update(Cart.x);
      |            ^~~~
In file included from libnml/cms/cms_pm.cc:16:
libnml/cms/cms.hh:31:8: note: forward declaration of ‘struct PM_CARTESIAN’
   31 | struct PM_CARTESIAN;
      |        ^~~~~~~~~~~~
libnml/cms/cms_pm.cc:22:12: error: invalid use of incomplete type ‘struct PM_CARTESIAN’
   22 |     update(Cart.y);
      |            ^~~~
libnml/cms/cms.hh:31:8: note: forward declaration of ‘struct PM_CARTESIAN’
   31 | struct PM_CARTESIAN;
      |        ^~~~~~~~~~~~
libnml/cms/cms_pm.cc:23:12: error: invalid use of incomplete type ‘struct PM_CARTESIAN’
   23 |     update(Cart.z);
      |            ^~~~
libnml/cms/cms.hh:31:8: note: forward declaration of ‘struct PM_CARTESIAN’
   31 | struct PM_CARTESIAN;
      |        ^~~~~~~~~~~~
libnml/cms/cms_pm.cc: In member function ‘CMS_STATUS CMS::update(PM_CARTESIAN*, int)’:
libnml/cms/cms_pm.cc:31:19: error: invalid use of incomplete type ‘struct PM_CARTESIAN’
   31 |         update(x[i]);
      |                   ^
libnml/cms/cms.hh:31:8: note: forward declaration of ‘struct PM_CARTESIAN’
   31 | struct PM_CARTESIAN;
      |        ^~~~~~~~~~~~
libnml/cms/cms_pm.cc: In member function ‘CMS_STATUS CMS::update(PM_SPHERICAL&)’:
libnml/cms/cms_pm.cc:38:12: error: invalid use of incomplete type ‘struct PM_SPHERICAL’
   38 |     update(Sph.theta);
      |            ^~~
libnml/cms/cms.hh:41:8: note: forward declaration of ‘struct PM_SPHERICAL’
   41 | struct PM_SPHERICAL;
      |        ^~~~~~~~~~~~
libnml/cms/cms_pm.cc:39:12: error: invalid use of incomplete type ‘struct PM_SPHERICAL’
   39 |     update(Sph.phi);
      |            ^~~

....

[andypugh]

I never expected this to compile (and even less work).
I did this so that we could see what needed to change to switch to the Tormach TP. I was actually surprised to find that it looked like a fairly clean merge (it helps that a lot of the changes involve breaking out functions into new files)

23eba66#diff-da68bc4b06ffe02ed3538bf29569a95ddbb12bb2f096c865c15752eac9c130a5L113

In this case it looks like PM_CARTESIAN as a macro has been replaced by PmCartesian. (though Github CoPilot disagrees)

(I don't even know what cms does, it's one of the more mysteriious corners of LinuxCNC)

[f355]

I have thrown my industrial-grade stochastic parrot at this diff, and it doesn't look like we're missing much. the wall of text below is what it deemed useful for the machinists after analyzing the code.

• Enhanced rigid tapping/spindle sync robustness

  • What: Dynamic reversal/overshoot estimation (latency/accel aware), reversal_scale, richer sync state machine/modes beyond basic position/velocity, better atspeed/index waits and transitions.
  • Why: Reduces tap breakage and scrap; more reliable tapping across machines and spindles.
  • Deps: None beyond current rigid-tap core.
  • Complexity/Risk: Medium–High.

• Dwell as a trajectory segment (TC_DWELL), with optional delta-RPM

  • What: Planner-level dwell inserted in the motion queue; optional spindle delta-rpm during dwell.
  • Why: Precise, predictable pauses that blend with motion; useful for coolant/settle/material-specific pauses.
  • Deps: New TC type + simple state handling.
    *Complexity/Risk: Medium, low operational risk.

• Separate linear vs angular velocity limits

  • What: tpSetVlimit(...) variants to set distinct linear and rotary limits, applied per-axis when planning.
  • Why: Real machines often have much slower rotaries; avoids penalizing linear feed or overdriving A/B/C.
  • Deps: Planner limit application updates.
  • Complexity/Risk: Medium.

• Normal (centripetal) acceleration limiting on arcs

  • What: Explicit cap on normal acceleration along circular paths in addition to tangential accel/jerk.
  • Why: Prevents following error/ringing on fast arcs; improves surface finish and reliability.
  • Deps: Arc kinematics and segment max-vel computation.
  • Complexity/Risk: Medium.

• 9D bi‑arc/spherical blending (XYZUVWABC)

  • What: Extend arc blend to operate across linear+rotary axes (SphericalArc9/biarc solver), not only 3D.
  • Why: Smoother blends when rotary axes are active; higher throughput without visible marks at blends.
  • Deps: 9D vector/matrix infra (PmVector/SphericalArc9).
  • Complexity/Risk: High.

• Index rotary gating improvements

  • What: Explicit IndexRotaryAxis abstraction and safer gating around index/unlock/lock during blends.
  • Why: Predictable, safe A-axis indexing workflows on combo milling/indexing jobs.
  • Deps: Minor TP and mot interface changes.
  • Complexity/Risk: Low–Medium.

[andypugh]

It's this bit that we want:
9D bi‑arc/spherical blending (XYZUVWABC)

Hopefully this will address the common problem reported with combined rotary and linear moves in cases where the G-code is many small moves and 1-segment lookahead is the bottleneck.

I have wondered if AI can help with large merges like this, but haven't found a free tool to try it with. (and I trust myself a little more than AI)

[rmu75]

@andypugh this is not the same codebase like in the zip-file i got. I emailed some other observations, gmail probably ate those emails (or put them into the spam folder).

[f355]

@andypugh or others, do you happen to have the test suite for these changes? I think I've managed to beat my stochastic parrot into reimplementing this properly on top of the master branch, but I'd like to test it more.

[andypugh]

Have you implemented the version in the PR as a separate pluggable TP or have you merged the changes into the existing one?

I can look in the Tormach code that I have to see if it has any more test cases in there.

Do you see any speed increase in cases where there are combined linear and rotary moves?
(This isn't quite the same issue as described here, which concerns the difference in units between linear and rotary moves:
https://www.youtube.com/watch?v=d0ffiCekhpE )

Where I would expect to see a difference would be in the case of a number of very short linear moves combined with a rotary move. I would hope that with these changes the linear + rotary would complete in the same time as the linear alone)

[f355]

@andypugh just in case the email misbehaves - I got your latest message and I've sent a response, let me know here if you have not received it.