vcswatch reports that
this package seems to have a new changelog entry (version
1:2.10.0~pre1, distribution
UNRELEASED) and new commits
in its VCS. You should consider whether it's time to make
an upload.
Here are the relevant commit messages:
commit 6136221d1b3a908f5be12ca4fef5a3f178ae0439
Author: Rene Hopf <renehopf@mac.com>
Date: Sun Sep 13 19:25:33 2026 +0200
fix encoder test syntax
commit adbc11f244e9c0bdf17ac4a5b435c1673a6938db
Author: Rene Hopf <renehopf@mac.com>
Date: Sun Sep 13 18:58:52 2026 +0200
add abs encoder test
commit 552f1d4f041f8a851be3091a4a284d9466580b61
Merge: f5aeb26a dd394d90
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 15:50:49 2026 +0200
Merge pull request #4513 from grandixximo/rtai-driver-deprecate
Remove the RTAI-kernel-only hardware drivers
commit f5aeb26a1793f9ae9c62081fd16352b26b9567cf
Merge: e63cf163 bd51c0d3
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Sep 13 09:26:14 2026 -0400
Merge pull request #4414 from grandixximo/g121-kins
G12.1, G13.1: select the kinematics type from G-code
commit dd394d90d0ac531b4a95c86e1b80817069244df3
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Sep 13 20:20:15 2026 +0800
Remove the RTAI-kernel-only hardware drivers
These drivers only ever built for RTAI kernels and were excluded from
uspace builds since 2014, so no current install could load them:
hal_stg, hal_motenc, hal_vti, hal_evoreg, hal_tiro, hal_ax5214h,
opto_ac5, pci_8255, pcl720, pluto_servo, pluto_step
All serve early-2000s ISA/PCI/parport cards. A poll on the forum and
emc-developers found zero users with the hardware, Vital Systems
reports no Motenc cards remaining and none known in use, and no
testers are available, so a uspace port cannot be validated either.
At the weekly meeting the decision was to remove them outright rather
than deprecate.
Also remove hal_skeleton (a kbuild-era code template), the now unused
rbf2h.py firmware header generator, the pluto firmware trees
(unbuildable without an ancient Quartus), and the sample configs for
these cards (by_interface/pluto, servotogo, vigilant, vitalsystems,
by_machine/boss, attic/demo_mazak).
Driver docs, man pages, component-list rows and po4a masters go with
the drivers.
commit e63cf163cec1462bd88446577958e1179e136e1d
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Sep 13 20:58:13 2026 +0800
build: tighten the depclean and modclean comments
Follow-up to #4419: same content in fewer words. State where dependency files live under each BUILD_SYS, why removing them forces no recompilation, what stale .d files do to the build, and why the recipe is a find rather than $(RM) $(DEPS) $(RTDEPS).
commit 7b29e9c33b6e78ae34731e4532d801d107c04ac8
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 8 20:34:44 2026 +0800
build: wipe generated manpage tree on clean
GENERATED_MANPAGES depends on BUILD_SYS, so removing manpages by list
leaves stale files behind on uspace trees (e.g. the kbuild-only driver
manpages pluto_servo.9, pluto_step.9, pcl720.9). gen_complist.py then
picks up the stale files and generates links to manpages the current
build configuration cannot produce, making local doc builds diverge
from CI.
Everything under docs/build/man is generated (halcompile output,
asciidoctor output from docs/src/man, alias pages, translations), so
wipe the whole tree in both clean-manpages and genclean.
commit 5c7ac76b2dbd6a9d1e098cb7911a3fc7b6a00d1c
Merge: 0649d32a c3e266fc
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 12:32:18 2026 +0200
Merge pull request #4419 from greatEndian/fix/depclean-userspace-deps
build: make depclean remove the userspace dependency files too
commit 0649d32a987cd1f60ede1be77f9b1135a4944f7c
Merge: d400df7f 88e1e025
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 12:32:05 2026 +0200
Merge pull request #4418 from greatEndian/fix/axis-jog-increment-units
axis: jog increments follow the selected axis type (degrees vs linear)
commit d400df7f3f1302cb55fc06c84c1c98976c0253fc
Merge: 24fd9146 6e97ff0e
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 12:22:22 2026 +0200
Merge pull request #4515 from grandixximo/tap-comp
hal: add tap component, UI override for bit outputs
commit 24fd9146ef13f77f469681a12e8edab7284f3807
Merge: e1b2897e 37b61f5e
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 12:14:49 2026 +0200
Merge pull request #4441 from grandixximo/g33-sync-fixes
Fix spindle position-sync jitter and catch infeasible thread pitches
commit e1b2897e4520ee53eb8ef511773b6b2231bd11ea
Merge: dc1b0e24 2ad450b9
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 12:14:16 2026 +0200
Merge pull request #4476 from alex-pres/pr-gremlin-draw-workpiece
preview: draw stock outlines from (WORKPIECE,...) comments
commit bd51c0d31396b500e3bd4e9ce628384417da25cb
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 12 20:11:00 2026 +0800
docs: G12.1 and G13.1 select the kinematics from G-code
The G-code reference gains G12.1 and G13.1, the switchkins chapter
describes the type declaration (switchkinsDeclare with
KINSTYPE_IDENTITY and KINSTYPE_PRIMARY, G13.1 resolving identity
from it) and leads with the deprecation notice for
motion.switchkins-type instead of offering the pin as an equal way
to switch. The motion man page follows.
commit a60a24b2618dc6791838122132625d7b9bee2a6f
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 12 20:10:48 2026 +0800
tests: selecting a kinematics from G-code
The machine stands in a pose the two kinematics disagree about,
which is the only place the codes can be tested: a switch between
kinematics that agree proves nothing. From there the test runs a
program in AUTO, where the interpreter reads far ahead of the
machine, and asks for a move along the one axis identity
kinematics carries on its own joint. Every other joint has to
hold, and the kinematics number has to reach the motion controller
and come back to the program.
It also puts G13.1 in an ON_ABORT_COMMAND routine. Such a routine
is run by a single execute() call that cannot service a queue
synchronisation point, so the switch has to leave one out there
and let the rest of the routine run. The routine ends with G54,
so the test leaves the machine in G55 and looks at which one comes
back.
The test module (5axiskins without identityfirst) has identity at
type 1, so G13.1 ends the program in type 1 and the program puts
the working kinematics back with G12.1 P0 by number. It selects
its starting kinematics explicitly: with G13.1 in the abort
routine, an estop reset already leaves the machine in identity, so
a program that assumes the boot kinematics proves nothing. The
check that the two kinematics disagree compares against the
programmed point rather than the live position readout.
commit 81020666a0cbe27578a5d0265d79d48589d78779
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 12 20:10:22 2026 +0800
configs: select kinematics with G12.1 in the switchkins sims
The switchkins sim configs chose their kinematics by writing
motion.switchkins-type through an analog output, the route motion
has just deprecated. The M428, M429 and M430 remaps, the TWP
wrappers behind G53.1, G53.3, G53.6 and G69, the abort handler
and remap.py now use G12.1 and G13.1. That drops the M66 sync
either side of every switch, the test that the HAL pin exists at
all, and the #5399 clobber each M66 costs, since G12.1 and G13.1
synchronise interpreter and motion themselves.
On pumakins, scarakins, genhexkins, genserkins and three21kins the
identity kinematics is type 1, so the M428 remaps there select the
module's working kinematics with G12.1 P#<kinstype> instead of
assuming type 0. The trsrn vismach guis and the halshow watch
lists follow motion.kins-type.
commit 0b09aebe1a8b60eeef07244f0ca6b0906799ddda
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 12 20:09:35 2026 +0800
motion: deprecate selecting the kinematics type from HAL
motion.switchkins-type cannot be the general way to choose
kinematics. The interpreter never sees it, so a program is read,
its limits checked and its path looked ahead in whatever
kinematics the interpreter last knew about, which need not be the
one that ends up running it. Nothing in the pin can fix that; the
interpreter has to be told, which is what G12.1 and G13.1 are for.
Motion says so once per session, the first time the pin is used to
change the type. A configuration that never switches never sees
it, and the G-code route never triggers it. The pin keeps
working; it is meant to go.
The selection's names now describe what they hold:
adjustKinsVar0 -> switchkins_type, an int
kinsType ('r'/'s' toggle) -> switchkins_seq, a counter
and the traj-prefixed status fields move into EMC_TRAJ_STAT where
they belong.
commit 57850283e984d6a3942eb67bce06654ffe45f6b1
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 12 20:07:52 2026 +0800
G12.1, G13.1: select kinematics from G-code
G12.1 P- selects one of the kinematics offered by a switchable
module, G13.1 cancels to the type the module declares as identity.
Both are queue synchronisation points, so no motion is planned in
one kinematics and executed in another. A cancel lands in the
state that always solves, like G49 or G69, not in whatever happens
to be numbered zero.
A switchable module that declares no identity type refuses G13.1
with an error pointing at the switchkins documentation and goes on
taking G12.1 P- by number; a P word naming a type the module does
not provide is a read-time error rather than a mid-program motion
abort. Where no kinematics is attached (sai, the preview) both
codes fall back to type 0.
Until now the only way to switch from a program was to write
motion.switchkins-type through an analog output and force a sync
by hand, typically M68 E3 Q1 followed by M66 E0 L0, wrapped in a
subroutine or a remapped M-code. Motion takes the G-code request
and the pin on their edges, so whichever asked most recently wins.
motion.kins-type reports the selection in force.
Nothing cancels the selection implicitly. It survives program end
and abort so the kinematics keeps matching the position readout,
since switching re-derives world position from the joints. To put
back a caller's selection:
#<saved> = #<_kins_type>
G12.1 P2
( ... )
G12.1 P#<saved>
#<_kins_type> reads back from motion on every synch, so it stays
right across an abort, which drops a queued switch, and across a
switch made from HAL behind the interpreter's back. Status has a
single writer: motion, which records the type only once the module
confirms the switch, so a refused type leaves the pin, the status
and #<_kins_type> on the kinematics still running, and names the
refusal to the operator.
Q was parsed and carried to motion without anything reading it, so
it is gone.
EMC_ADJUST_KINS_OFFSET_DATA is registered in the NML format and
name tables and has the update() its declaration promised, without
which the message could not cross the channel.
commit e6e928b8d7897275af6f3472a412888df5d7b62e
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 12 20:03:28 2026 +0800
kinematics: a switchkins module declares what each type is
A kinematics number says nothing about what the kinematics IS.
Give the module a way to say it: switchkinsDeclare(ktype, flags)
from switchkinsSetup(), with KINSTYPE_IDENTITY and
KINSTYPE_PRIMARY from kinematics.h. A module that declares
nothing keeps working, its types numeric-only.
The declarations are static once loaded, so they travel to the
interpreter through the status channel: motion copies
kinematicsTypeFlags() into emcmotStatus at load, task mirrors them
into EMC_TRAJ_STAT, and a GET_EXTERNAL_KINS_TYPE_FLAGS() canon
accessor reads them there. -1 marks a type the module does not
provide, and the stat buffer initializes to that, so before the
first status lands the answer is "unknown", not "declared
nothing".
Declaring a type the module does not provide, or declaring two
identity types, fails the module load.
The in-tree modules declare their types next to the function
tables they describe. The trt modules and 5axiskins follow their
identityfirst sparm, so the declaration tracks the layout the
config actually gets. The hand-rolled switchable comps (the two
trsrn, the tdr and millturn) answer kinematicsTypeFlags()
directly, the way they answer kinematicsSwitchable().
commit dc1b0e24020dfe0df8a2a3c51ddc4a1024111368
Merge: 7804865c f6a15084
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 11:50:20 2026 +0200
Merge pull request #4416 from grandixximo/g53-rotary-tool-offset
rs274ngc: back the rotary tool offset out of machine coordinates
commit 7804865c35d176f9ae143a6d25cbba640674eb86
Merge: f35f8a5b 39d821c6
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 11:38:22 2026 +0200
Merge pull request #4455 from grandixximo/kins-tool-frame
kinematics: let a module report where the tool points
commit f35f8a5bc188c878b6a17e327d002ae10c4bd5d8
Merge: 80c120a0 f6c371c0
Author: BsAtHome <bertho@vagrearg.org>
Date: Sun Sep 13 11:12:47 2026 +0200
Merge pull request #4431 from grandixximo/kins-tool-offset
5axiskins, maxkins: take the tool length through a pin like every other rotary module
commit 80c120a065cb857ad7d5d655709b3f9094e88cfe
Merge: b26ce954 d7935fd9
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Sep 13 04:41:13 2026 -0400
Merge pull request #4343 from Sigma1912/Orient_Add-modes-with-index
Orient.comp: Add modes with preceding homing to index
commit b26ce9544fdb29179054ead942695abf36376163
Merge: 9e46ff87 85fe1de8
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Sep 13 04:11:51 2026 -0400
Merge pull request #4487 from grandixximo/g7x-flipflop
interp_g7x: make the G7x roughing cycle independent of rounding
commit 9e46ff870139c2ec4f19f5bd58cba65906d0e329
Author: Greg Carl <26096779+snowgoer540@users.noreply.github.com>
Date: Sat Sep 12 18:25:21 2026 -0400
qtplasmac: fix cut recovery bug
Fix cut recovery bug caused by trimming too much fat in commit 8862c57. Also addresses removed user buttons not being disabled, some interlocking template issues, and fixed the user manual URLs that were affected by recent doc URL structure changes.
commit bd7fb6c8d2cdb195c9929ddf587b785e5ca5685a
Merge: a693052b edb3f29d
Author: andypugh <andy@bodgesoc.org>
Date: Sat Sep 12 20:52:41 2026 +0100
Merge pull request #4520 from 85vmh/add_test_for_pr_4031_issue_3675
Added tests that cover aborting a pending tool prepare or tool change
commit edb3f29d5e34bd25e1c1e96e2373d73004afaac5
Author: 85vmh <vasimihalca@gmail.com>
Date: Sat Sep 12 21:23:04 2026 +0200
tests: cover aborting a pending tool prepare or tool change
The problem
-----------
Commit 764655eb4d moved IO handling out of the separate iocontrol process and
into Task. The old NML dispatcher set RCS_DONE by default for every command it
handled; the in-process emcIoAbort() did not, so EMC_TOOL_ABORT dropped the
tool-change and tool-prepare output pins but left emcioStatus.status at the
RCS_EXEC that emcToolPrepare()/emcToolLoad() had set.
Nothing could clear it afterwards. read_tool_inputs() only reports completion
while the corresponding output pin is still high, and the abort had just
lowered it, so the handshake it waits for could never be observed. Because the
MDI, auto and state-restore paths in emctaskmain gate on io.status == RCS_DONE,
aborting while a tool change was pending wedged task: no further MDI command or
program run would start, and the machine had to be restarted.
The fix
-------
Fixed in commit 990cb293bd, "task: set io.status=DONE on emcIoAbort to unblock
tool-change abort" (PR #4031, closes issue #3675), which sets
emcioStatus.status back to RCS_DONE in Task::emcIoAbort().
That fix landed without a regression test. This commit adds one; it contains no
functional change.
What the test covers
--------------------
tests/toolchanger/abort-during-change drives a sim machine whose tool-prepare
and tool-change handshake pins are brought out to the test itself rather than
looped back, so the test can leave a change pending for as long as it likes and
abort in the middle of it. It checks four things:
- a complete T1 M6 works, so the rest of the run starts from a known state;
- aborting while tool PREPARE is pending returns the machine to RCS_DONE, the
tool in the spindle is unchanged, and MDI still runs -- proving task is not
stuck in WAITING_FOR_IO;
- aborting while tool CHANGE is pending does the same. The tool in the spindle
is asserted to be the *old* one: satisfying the status check by pretending
the change completed would pass the RCS_DONE assertion but fail here;
- a full tool change still succeeds after both aborts, so the abort path does
not leave the tool-change state machine unusable.
The test fails against a tree with the emcIoAbort() line from 990cb293bd removed
and passes with it, and the surrounding tests/toolchanger tests are unaffected.
The layout follows the existing tests/toolchanger/m61 test; mod_core_sim.hal and
postgui.hal are that test's files unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
commit a693052b3d8ce6f3c2c73a5704958c87cd3e7781
Author: Rene Hopf <renehopf@mac.com>
Date: Sat Sep 12 19:07:34 2026 +0200
fix gmoccapy jog pin
commit 5622d3f98a0599d9e4c964c9fca4aaaf6682541e
Author: Rene Hopf <renehopf@mac.com>
Date: Sat Sep 12 18:55:10 2026 +0200
fix type of motion doc
commit 6e97ff0e7779fb548e4cb193418a16eea7757fc3
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 12 21:37:48 2026 +0800
hal: add tap component
tap sits between a HAL boolean signal (typically driven by HAL logic or
by G-code digital outputs such as M64/M65) and the output it controls.
Edges on the in pin pass the HAL logic state through to out and mirror
it to the io pin, so a UI always shows the current state. A UI can
force the output on or off via the io pin without MDI; the next edge
of in hands control back to the HAL logic.
Pins use the new bool API. The io edge is tested first so a UI
override is not immediately overwritten by the in handler mirroring
to io; a simultaneous in edge is consumed, io wins the tie.
Includes the extracted manpage documentation, a components.adoc
entry, and a tests/tap.0 regression test (test.hal driven, using
hal.set_p/hal.get_p and threadbeat-synchronized waits).
commit f325d51f52da7d5e0e227ac35e3672ee6f873b4f
Merge: 9138e20e c82f7278
Author: BsAtHome <bertho@vagrearg.org>
Date: Sat Sep 12 14:46:25 2026 +0200
Merge pull request #4516 from Sigma1912/Vismach-Fix-Track
Fix: vismach.py, fix valueError and recurrant message in Track()
commit c82f7278f0d4ce179b32444c38bbab18a8734f13
Author: david mueller <mueller_david@hotmail.com>
Date: Fri Sep 11 19:57:00 2026 +0200
Fix: vismach.py, fix valueError and recurrant message in Track()
- Stop printing message on every cycle while waiting for the scene
- Check length of array instead of comparing to an empty list
commit 9138e20e58da5cf16e50ef603f19dada87b99ba8
Merge: 432561ec 467684c2
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Thu Sep 10 19:57:02 2026 -0400
Merge pull request #4512 from weblate/weblate-linuxcnc-linuxcnc-docs
Translations update from Hosted Weblate
commit 432561eca28d7fe72eef17541945f1e8b0c3c2e8
Merge: e646ce0a 2ed0aaea
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Thu Sep 10 19:42:39 2026 -0400
Merge pull request #4511 from weblate/weblate-linuxcnc-linuxcnc
Translations update from Hosted Weblate
commit 467684c272ac151534f6015c7b3d5b7b4f2adea9
Author: Américo Monteiro <a_monteiro@gmx.com>
Date: Fri Sep 11 01:07:32 2026 +0200
Translated using Weblate (Portuguese)
Currently translated at 34.1% (11614 of 33994 strings)
Author: Américo Monteiro <a_monteiro@gmx.com>
Co-authored-by: Américo Monteiro <a_monteiro@gmx.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/pt/
Translation: LinuxCNC/LinuxCNC Documentation
commit 2ed0aaeaae4977560c2b7b9233b31d1627760823
Author: Daniel Nylander <yeagersthlm@gmail.com>
Date: Fri Sep 11 01:07:32 2026 +0200
Translated using Weblate (Swedish)
Currently translated at 100.0% (420 of 420 strings)
Co-authored-by: Daniel Nylander <yeagersthlm@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/gmocappy/sv/
Translation: LinuxCNC/LinuxCNC/Gmocappy
commit 46a21c8e0795b0909a125c9a01a936a677ba5003
Author: Salvador Peña <salvadorp74@hotmail.com>
Date: Fri Sep 11 01:07:31 2026 +0200
Translated using Weblate (Spanish)
Currently translated at 35.9% (12218 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Translated using Weblate (Spanish)
Currently translated at 35.9% (12218 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Translated using Weblate (Spanish)
Currently translated at 35.9% (12215 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Co-authored-by: Salvador Peña <salvadorp74@hotmail.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translation: LinuxCNC/LinuxCNC Documentation
commit e646ce0ad8b5f0c7024b25cad63537a0609a2787
Merge: 64efb28c 4d4124ae
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Wed Sep 9 18:24:57 2026 -0400
Merge pull request #4509 from weblate/weblate-linuxcnc-linuxcnc-docs
Translations update from Hosted Weblate
commit 4d4124ae4800d60d234459a81e5162c8eb6b4ac5
Author: Salvador Peña <salvadorp74@hotmail.com>
Date: Wed Sep 9 18:02:15 2026 +0200
Translated using Weblate (Spanish)
Currently translated at 35.4% (12037 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Co-authored-by: Salvador Peña <salvadorp74@hotmail.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translation: LinuxCNC/LinuxCNC Documentation
commit 767740f3015ffda42801551280f16eccbee9c924
Author: Luca Toniolo <toniolo.luca@outlook.com>
Date: Wed Sep 9 18:02:14 2026 +0200
Translated using Weblate (Ukrainian)
Currently translated at 99.6% (33879 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (German)
Currently translated at 99.6% (33891 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (French)
Currently translated at 2.4% (828 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Spanish)
Currently translated at 35.4% (12037 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Co-authored-by: Luca Toniolo <toniolo.luca@outlook.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/de/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/fr/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/uk/
Translation: LinuxCNC/LinuxCNC Documentation
commit 64efb28cd77a16b45ade81e576c784cdc574f40e
Merge: a1d46dbe be5cf546
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 8 02:11:09 2026 -0400
Merge pull request #4506 from grandixximo/gmoccapy-early-sigterm
gmoccapy: arm a minimal SIGTERM handler before the slow startup phase
commit be5cf546e28e6fd7d4022cbf6c4c586e4237346b
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 8 13:36:32 2026 +0800
gmoccapy: arm a minimal SIGTERM handler before the slow startup phase
699af8e5ae arms the full SIGTERM/SIGINT handler only right before
Gtk.main(). A shutdown SIGTERM landing earlier, during the imports or
app construction, hits the default disposition and kills the process
mid-startup: no SystemExit unwind, so the atexit child cleanup and the
_hal Py_AtExit hook never run. On a loaded machine this window
stretches past task startup, so real shutdowns and the ui-smoke
gmoccapy-quit driver can land SIGTERM in it.
Install a minimal handler that exits through SystemExit as the first
action of the script; the full handler replaces it when installed.
Verified locally: SIGTERM in the import window now exits 0 with a
clean linuxcnc shutdown, where the unpatched script died with 143.
commit c3e266fc6d317fc0413a755ca28360c2f0875ec5
Author: greatEndian <chabron94@gmail.com>
Date: Wed Aug 19 10:12:36 2026 -0400
build: make depclean remove the userspace dependency files too
depclean removed only 'depends'. Under BUILD_SYS=normal that directory
holds the realtime dependency files; under the default BUILD_SYS=uspace
'depends' is never created at all. Every other dependency file is
written next to its object as objects/**/*.d -- realtime included on a
uspace build -- and depclean never touched them. On the default build
that made depclean a complete no-op: it rm -rf'd a directory that never
existed.
That matters when a source file is renamed or moved. A stale dependency
file still declares, say
objects/hal/utils/halrmt.o: hal/utils/halrmt.c
and gcc's -MP writes dummy targets for the *headers* only, never for the
main source, so once hal/utils/halrmt.c is gone nothing can satisfy that
prerequisite and the whole build stops with
make: *** No rule to make target 'hal/utils/halrmt.c',
needed by 'objects/hal/utils/halrmt.o'. Stop.
The obvious remedy is 'make depclean', and it did not help: the only way
out was 'make clean' and a full rebuild. Hit in practice on a
run-in-place tree carried across the halrmt.c -> halrmt.cc rename and the
src/libnml/posemath -> src/libposemath move; eight dependency files
pointed at sources that no longer existed.
Removing the files costs no recompilation -- nothing has a .d as a
prerequisite, and UNREAD_DEPS is computed but never used -- so this only
gives up header-dependency tracking until each object is next rebuilt,
which is what asking for depclean means.
The comment above modclean is corrected as well: 'clean' does remove the
dependency files today, because genclean deletes objects/ wholesale.
commit a1d46dbeaaa03ed15f447139418414f1179bd3ac
Merge: 76156126 ed8c87a2
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Mon Sep 7 07:16:42 2026 -0400
Merge pull request #4420 from greatEndian/fix/ruckig-log-flood
tp: rate-limit Ruckig plan-failure logging to once per segment
commit ed8c87a29b98752ba26f4d02a0122e7ab9d182ce
Author: greatEndian <chabron94@gmail.com>
Date: Fri Jun 26 10:28:10 2026 -0400
tp: rate-limit Ruckig plan-failure logging to once per segment
A segment whose inputs Ruckig can never solve keeps ruckig_planned=0,
so tpCalculateSCurveAccel re-enters its failure branch every servo
cycle and logs at the full servo rate (e.g. 1kHz). Motion is
unaffected (it falls back to trapezoidal), but over a long run this
floods the kernel log / journald with GBs of identical records.
Add per-segment "already logged" flags to TC_STRUCT (reset by tcInit
on every new segment) and log each failure once, tagged with the
segment id. Not re-armed on a later success within the same segment,
so an oscillating fail/succeed segment also cannot flood. No change to
motion behaviour. master's own tpCalculateSCurveAccel already carries a
scurve_jerk_warned once-only guard for the adjacent warning.
tpCalculateSCurveAccel has five distinct Ruckig failure sites, each
retried every servo cycle:
- pool acquire: ruckig_planner stays NULL and is re-acquired next cycle
for as long as the preallocated pool is exhausted;
- velocity control, replan failed: keeps the previous trajectory and
falls straight back in on the next cycle;
- velocity control, first attempt failed: returns
TP_SCURVE_ACCEL_ERROR, which only makes the caller use trapezoidal
for that one cycle before calling back in;
- position control, replan failed / first attempt failed: the same two
cases on the position-control path.
Each site gets its own flag rather than one shared flag, so a segment
that hits more than one failure mode (e.g. pool-acquire, then a plan
failure once a planner frees up) still logs each mode once. A single
shared flag would report only whichever fired first.
The first-attempt position-control ERR dump also regains plan_result,
which was previously only on the replan branch, so the give-up path
again shows which limit Ruckig objected to. The velocity-control
first-attempt warning carries it too, for symmetry.
commit 76156126d8b12985eeb1cc70ae0215d6fa5f7233
Merge: 14d739aa 63532ab1
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Sep 6 21:50:02 2026 -0400
Merge pull request #4504 from weblate/weblate-linuxcnc-linuxcnc-docs
Translations update from Hosted Weblate
commit 63532ab13ed98e60085ae7da2e83f1c7d1e0550f
Author: Américo Monteiro <a_monteiro@gmx.com>
Date: Mon Sep 7 02:52:54 2026 +0200
Translated using Weblate (Portuguese)
Currently translated at 34.1% (11595 of 33994 strings)
Author: Américo Monteiro <a_monteiro@gmx.com>
Co-authored-by: Américo Monteiro <a_monteiro@gmx.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/pt/
Translation: LinuxCNC/LinuxCNC Documentation
commit e09b576d161818fa302877646c370271a7ed3359
Author: Salvador Peña <salvadorp74@hotmail.com>
Date: Mon Sep 7 02:52:52 2026 +0200
Translated using Weblate (Spanish)
Currently translated at 35.3% (12022 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Co-authored-by: Salvador Peña <salvadorp74@hotmail.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translation: LinuxCNC/LinuxCNC Documentation
commit ade964b269d4120284b0e305eff3f907f0f75dbf
Author: Luca Toniolo <toniolo.luca@outlook.com>
Date: Mon Sep 7 02:52:49 2026 +0200
Translated using Weblate (Tamil)
Currently translated at 81.4% (27689 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Portuguese)
Currently translated at 34.1% (11595 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Ukrainian)
Currently translated at 99.6% (33879 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Russian)
Currently translated at 34.3% (11669 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (German)
Currently translated at 99.6% (33891 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Chinese (Simplified Han script))
Currently translated at 1.3% (450 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Norwegian Bokmål)
Currently translated at 4.4% (1503 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (French)
Currently translated at 2.4% (827 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Spanish)
Currently translated at 35.3% (12022 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Co-authored-by: Luca Toniolo <toniolo.luca@outlook.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/de/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/fr/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/nb_NO/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/pt/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/ru/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/ta/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/uk/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/zh_Hans/
Translation: LinuxCNC/LinuxCNC Documentation
commit 14d739aa99587b1c467640c5907ed806936cf475
Author: Cmorley <chrisinnanaimo@hotmail.com>
Date: Sat Sep 5 19:03:13 2026 -0700
qtvcp -3pcenter panel: update for small improvements
Better feedback text, better goto position path.
MarkoPolo
commit 39d821c64f2a0ec37c1f534abfc8ea94250e5116
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Fri Sep 4 19:14:49 2026 +1000
kinematics: take the tool frame inverse request as a program writes it
The search solves to a residual of 1e-18, and a direction written to six digits is a unit vector only to 1e-7, so a request copied from a program was reported unreachable. Normalise the axis on the way in, and take the component along it off the requested tool x, refusing only a zero vector or a tool x within a millionth of a radian of the axis, since neither describes a frame.
commit 6f45f6a7b973d54f8fe1bc6e2bddaaa1bbc9a02c
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Fri Sep 4 19:14:39 2026 +1000
kinematics: let the caller hold joints in the tool frame inverse
A rotary table turns the tool against the work as surely as a head rotary does, so on a machine with a table and a two axis head the solver had three orientation joints and a bare tool axis left a family, of which it reported the member nearest the seed; asked for tool x as well it turned the table to place it and reported no spin. The tilted work plane remap does the opposite: it holds the table, orients the head and applies the spin as the virtual rotation. Neither is wrong, and which is wanted is a machining decision; Heidenhain names the axes a tilt may use with M138 and lets PLANE choose TABLE ROT or COORD ROT.
So the request names the joints to hold, a bit per joint, zero for none. A held joint keeps its seed value and the request is solved with the rest. Holding the table gives the two head solutions and the spin that finishes the frame, which is what the remap computes.
commit 3524f95228c92a52eab648e436603595a420167d
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Fri Sep 4 19:11:47 2026 +1000
kinematics: the tool frame is the joints' alone
The header said that a module applying a virtual rotation about the tool axis reports a frame that includes it. No module does, and none should: the rotation is a rotation of the coordinate system, not of the machine, which is where Heidenhain's COORD ROT, Fanuc's feature coordinate system and Siemens' swivel frame keep it. Reporting the joints alone also keeps the orientation inverse honest, since the turn it reports about the tool axis is then the value to apply and not a difference from whatever is applied already.
Found by putting the two trsrn components next to the tilted work plane python: the frames agree exactly at zero virtual rotation and differ by exactly Rz(pre-rot) otherwise. Say so in the header and the chapter.
commit ade0664620662517dc921ab6bfe5248eec463cd9
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Wed Aug 26 19:07:39 2026 +1000
tests: check the shipped frame functions where they run
The frame cases so far run machines written for the test, so the
hand-written matrix entries in each module are compiled and nothing
more, and that is where a sign or a transposed pair hides.
Run them in service instead: a realtime component loaded after the
module under test, reaching it through the same exported entry points
motion uses, for every kinematics type the module offers. A failed
check fails the load, and a failed load fails the test.
The work frame is checked against the forward kinematics rather than
against a matrix copied out of the module: a row of the work frame is
how the reported position responds to one machine axis, by central
difference.
The tool frame has no such tie on a machine that carries the work, so
what is checked is that the frame is a rotation, that a spindle the
module calls fixed never moves, and that a joint carrying the whole
head turns the reported frame about the machine's z and nothing else.
The last one catches a frame built for the wrong joint or composed in
the wrong order.
Checked by mutation, in failed checks: reversing the head composition
order in a trsrn module 300, a flipped sign in its work frame 150, one
in the xyzac work frame 18, the wrong spindle convention there 25, a
flipped sign in the puma flange 72. The tree as it stands fails none.
commit 340032d425ae0ed59d4fcf57c78c7c5f661ccfc2
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Wed Aug 26 21:49:16 2026 +1000
trsrn: set the kinematics pins up once, at load
Both modules build their pins on the first kinematicsType() call and
test an is_setup flag that nothing ever sets, so every later call runs
the setup again. The second run reassigns haldata to a fresh block and
then fails to create the pins that block points at, all of them already
taken, so the module is left reading through null references and the
next forward or inverse call takes realtime with it.
Motion asks twice when num_extrajoints is greater than zero, once in
rtapi_app_main and once in init_comm_buffers, so that combination
cannot be running today.
Latching the flag would stop the repeat, but the setup does not belong
in a function whose job is to answer a question. halcompile has a hook
for this, used by homecomp for the same reason: EXTRA_SETUP() runs once
from the generated setup, before the component is made ready. So the
pins exist from the moment the module is loaded, kinematicsType() only
answers, and the hal_set_unready() and hal_ready() calls the old
placement needed are gone with it.
commit 2ae7c8a6f4236eec0d21e5cae7cd0f8ab0621ffd
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Mon Aug 24 14:18:03 2026 +1000
kinematics: answer which joints point the tool somewhere
The frames say where the tool points for a set of joint values. The question
a tilted work plane actually asks is the other way round: which joint values
point it at the orientation the program wants. Today that is answered outside
the kinematics, in per-machine trigonometry in the TWP remap, once per machine
and once per pair of rotary letters, which is how the copy in the tree came to
check the primary angle against the secondary joint's limits.
kinematicsToolFrameInverse() asks the module instead. It reports every set of
joint values that reaches the orientation, and nothing else: no joint limits
and no preference between the answers, because the caller knows the limits and
knows whether the operator asked for the shortest move or for one direction of
rotation only. A module that reports its frames needs to supply nothing, the
generic search in kins_util.c drives them; a module with a closed form
registers it and that is used instead.
The request is a tool axis and optionally a tool x as well, and asking for tool
x does not require a joint that can reach it. A five axis machine spends both
rotaries on the tool axis and the turn about that axis is not a joint, it is
the virtual rotation, so the answer comes back in two parts: the poses that
reach the axis, and the turn that places tool x, which is zero where a third
orientation joint did the job instead. The caller writes one path and the kind
of machine becomes a number rather than a branch. That is what the controls
do, a Heidenhain PLANE VECTOR block carrying the normal and the base vector
together and a Fanuc G68.2 defining where the plane's X points; neither refuses
a program for naming both.
Where a request still leaves the machine free, at a singular pose or on a
machine with a spare orientation joint, one point of the family is reported,
the one nearest the seed, with the number of free directions alongside.
Returning samples of a curve as though they were alternatives would be worse
than saying so.
Three details in the search are not incidental. The damping is adaptive,
which is what keeps a rank deficient pose from turning finite difference noise
into a step of thousands of degrees. The Jacobian is central differenced,
because a one sided error is first order in the step and shows up as a
spurious singular value, which is exactly what the rank test must not see.
And the joint unit is discovered by adding a whole turn and asking whether the
frame came back, because every module in the tree takes degrees but the
interface does not say so.
The unit test drives it through a table rotary machine, a nutating head and a
machine with both, and checks the nutating answers against the closed form the
remap uses.
commit 8bf4605ae81042248add031e94c77300406e0413
Merge: fa910f12 699af8e5
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Fri Sep 4 20:23:04 2026 -0400
Merge pull request #4501 from grandixximo/gmoccapy-quit-4500
gmoccapy: fix SIGTERM/SIGINT hang while a modal dialog is up
commit 699af8e5ae645788355be42437804795afcc363f
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Sep 5 07:29:15 2026 +0800
gmoccapy: fix SIGTERM/SIGINT hang while a modal dialog is up
A modal dialog's gtk_dialog_run() loop is invisible to Gtk.main_quit(), so the GUI survived SIGTERM and the ui-smoke gmoccapy-quit test timed out. _terminate now destroys all other toplevels so run() returns and the unwind proceeds, with a forced exit as backstop.
Also guard set_max_undo_levels() in hal_sourceview (dropped by newer GtkSourceView 4; the AttributeError popped the modal error dialog on CI), and harden the excepthook against a partially built app object.
commit fa910f12394ba1b76edc4c5b3ac67955d9d79ace
Author: Cmorley <chrisinnanaimo@hotmail.com>
Date: Wed Sep 2 18:32:31 2026 -0700
axis/gmoccapy -docs: add info qtvcp is embedable too
commit ee0ed55ec2e0662d2805519308a7859cd927e8f4
Author: Cmorley <chrisinnanaimo@hotmail.com>
Date: Wed Sep 2 06:03:03 2026 -0700
qtvcp -docs : add missing center finder image
commit dc61c5a384784882a6f86125fe38b1780afd5d92
Merge: 098cd98a a4cd6d9a
Author: BsAtHome <bertho@vagrearg.org>
Date: Wed Sep 2 10:59:31 2026 +0200
Merge pull request #4136 from grandixximo/ui-tests-phase3
ui-smoke phase 3: screenshots, writable config mirrors, homing settle
commit a4cd6d9ad459762e64b554f0239d09af2d70c098
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Wed Sep 2 15:08:36 2026 +0800
tests: ui-smoke phase 3, screenshots, reference diffs, crash dumps, driver hardening
Each GUI smoke test now captures a screenshot on failure and a settled confirm shot on pass, uploaded as CI artifacts. The confirm shot is compared against a committed reference.png at 0% fuzz, writing red-highlight and absolute-difference diff images; the comparison never fails a test, it records rendering drift (freetype versions differ across distros) so preview regressions are visible at review time.
Crash dumps: runtests -d opts in; on a crashing GUI test a gdb backtrace is printed from the core, collected via coredumpctl on systemd hosts or a plain-file core_pattern the CI workflow arms at job level. No sudo in the test scripts. gdb moves to control build-deps so package-arch tests have it too.
gmoccapy runs against a writable config mirror with a seeded preference file so the first-run modal stays hidden; PROGRAM_PREFIX is pointed at the real nc_files for the mirror.
Driver hardening: ensure_state/ensure_mode re-verify with a retry budget, and home_all / run_program retry their whole command sequence, so a late GUI startup revert (gmoccapy's own ESTOP or mode reset landing after the state checks) costs one retry instead of failing the test. No fixed sleep in the driver is load-bearing; the settles only keep transient warning dialogs out of the screenshots.
Adds the touchy-fit test: boots touchy on a 1024x768 screen and fails if the window exceeds it.
commit 098cd98a6c03cc6fa8748b862e5fe09702529bae
Merge: 092cef0b 1017e5a1
Author: BsAtHome <bertho@vagrearg.org>
Date: Wed Sep 2 09:41:23 2026 +0200
Merge pull request #4496 from grandixximo/fix/docs-qtvcp-center-finder-image
docs: drop dangling qtvcp_center_finder image ref
commit 1017e5a19ca3a92dba10122ae8fb3bc802058765
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Wed Sep 2 03:06:59 2026 -0400
docs: drop dangling qtvcp_center_finder image ref
24eb9899c9 referenced the screenshot without committing it, which broke the docs build.
commit 092cef0b3075543b6bae233215e442b4d33bda47
Merge: 24eb9899 49570d43
Author: BsAtHome <bertho@vagrearg.org>
Date: Wed Sep 2 08:53:37 2026 +0200
Merge pull request #4495 from grandixximo/rs274ngc-drop-dead-rtapi-math
rs274ngc: drop dead rtapi_math.h includes
commit 24eb9899c9028335e33083217bb777f32effeb5c
Author: Cmorley <chrisinnanaimo@hotmail.com>
Date: Tue Sep 1 19:46:24 2026 -0700
qtvcp -add 3pcenter panel
find center with 2 points.
Donated by MarkoPolo
commit 49570d43eaf79a5769db132d39f20fe500b1f649
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 1 21:46:02 2026 -0400
rs274ngc: drop dead rtapi_math.h includes
interp_arc.cc, interp_execute.cc and interp_find.cc included
<rtapi_math.h> but use no rtapi_ symbols. Their math functions and
M_PIl come from <math.h>, which they already include after defining
_GNU_SOURCE. The interpreter is built only as the userspace
librs274.so, so the kernel branch of rtapi_math.h never applied.
Completes the include cleanup that #4493 did for interp_convert.cc
and interp_read.cc.
commit 10ca5afdb599878193562d284f0dd553542ec614
Merge: 7d381974 e0a4bb26
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 1 20:37:38 2026 -0400
Merge pull request #4491 from alex-pres/pr-interp-speedup-number-parse
optimization: rs274ngc: parse numbers with std::from_chars
commit 7d381974df563bc50a755d201c63272e383fa1ce
Merge: 1c6b998b cdeeaa40
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 1 20:37:07 2026 -0400
Merge pull request #4493 from BsAtHome/fix_rs274ngc-no-rtapi
rs274ngc: Don't use RTAPI. This is non-RT userspace code
commit 1c6b998b66b9c7ba42728565622f3489cddc1a57
Merge: ca409f39 02e9984c
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 1 20:13:59 2026 -0400
Merge pull request #4490 from BsAtHome/halgs_fix-tests-components
tests: Update all components in tests to getter/setter
commit ca409f3934546b1cab68c7ad95b1d041adf75192
Merge: d566b711 0c5566b0
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Tue Sep 1 18:29:38 2026 -0400
Merge pull request #4494 from weblate/weblate-linuxcnc-linuxcnc-docs
Translations update from Hosted Weblate
commit 0c5566b09191a52eeb8f506baead56b6a9c07182
Author: Américo Monteiro <a_monteiro@gmx.com>
Date: Tue Sep 1 17:53:02 2026 +0200
Translated using Weblate (Portuguese)
Currently translated at 32.6% (11108 of 33994 strings)
Author: Américo Monteiro <a_monteiro@gmx.com>
Co-authored-by: Américo Monteiro <a_monteiro@gmx.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/pt/
Translation: LinuxCNC/LinuxCNC Documentation
commit 105ee289278c6743573d5aba5037f9dfb224b9b2
Author: Luca Toniolo <toniolo.luca@outlook.com>
Date: Tue Sep 1 17:52:59 2026 +0200
Translated using Weblate (Tamil)
Currently translated at 81.4% (27681 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Ukrainian)
Currently translated at 99.6% (33878 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Russian)
Currently translated at 34.3% (11668 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (German)
Currently translated at 99.6% (33891 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Norwegian Bokmål)
Currently translated at 4.4% (1500 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (French)
Currently translated at 2.1% (715 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Spanish)
Currently translated at 35.0% (11903 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Co-authored-by: Luca Toniolo <toniolo.luca@outlook.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/de/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/fr/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/nb_NO/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/ru/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/ta/
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/uk/
Translation: LinuxCNC/LinuxCNC Documentation
commit b9b0dd787029c620cfe99c0ba7eb4523c71d5e29
Author: Salvador Peña <salvadorp74@hotmail.com>
Date: Tue Sep 1 17:52:51 2026 +0200
Translated using Weblate (Spanish)
Currently translated at 35.0% (11903 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Co-authored-by: Salvador Peña <salvadorp74@hotmail.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translation: LinuxCNC/LinuxCNC Documentation
commit cdeeaa409e5867f4850157ab0d18b6ddfe57ae60
Author: Bertho Stultiens <bertho@vagrearg.org>
Date: Tue Sep 1 14:48:23 2026 +0200
rs274ngc: Don't use RTAPI. This is non-RT userspace code.
commit e0a4bb26f63f6f807ae6832de5b78c42ed35de55
Author: Alexey Presnyakov <309782758+alex-pres@users.noreply.github.com>
Date: Mon Aug 31 20:34:12 2026 +0400
rs274ngc: parse numbers with std::from_chars
read_real_number built a std::string and a std::stringstream for every number
in a program, and read_integer_unsigned handed the digits it had already
delimited to sscanf("%d"). std::from_chars needs neither, and is
locale-independent where the stream was not. Accepted syntax, parsed values
and both error messages are unchanged, except that a magnitude too small for
a double, and a line number too large for an int, are now parse errors.
Parsing a 13.7M line program is 2.1x faster.
commit d566b71161a159a7f4fbbf61b9e6693f6b4bfbe4
Merge: 3f877213 37520737
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Mon Aug 31 07:12:52 2026 -0400
Merge pull request #4489 from BsAtHome/fix_hostmot2-llio-spidriver-retval
hostmot2: Fix the (superseded) SPI driver's low-level IO return values
commit 02e9984ccd72022d96697195434e884eb5fdf5be
Author: Bertho Stultiens <bertho@vagrearg.org>
Date: Sun Aug 30 18:03:07 2026 +0200
tests: Update all components in tests to getter/setter.
commit 3f87721343f2f6ad5940a2acac60a2c9262707f4
Merge: d17b036e 793a04c1
Author: BsAtHome <bertho@vagrearg.org>
Date: Mon Aug 31 00:22:32 2026 +0200
Merge pull request #4444 from grandixximo/fix/hal-gremlin-is-lathe
gladevcp: fix velocity DRO row position on non-lathes
commit 375207373eaf717634defa0e30ee396e03a95820
Author: Bertho Stultiens <bertho@vagrearg.org>
Date: Sun Aug 30 14:31:24 2026 +0200
hostmot2: Fix the (superseded) SPI driver's low-level IO return values.
commit 85fe1de84ae0544fbb8ce155129faf75eb4e0ec2
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Aug 29 22:22:50 2026 +1000
interp_g7x: build with the default floating point contraction again
The exception was there to keep the G71 tool path away from FMA while the
cycle still decided cases on exact float comparisons. It does not any
more, so the file can be built like every other one and CI is free to
catch it if some other part of the code cannot.
commit 60756289b8f2df966b178c1f86c18f0affb31eef
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Aug 29 20:19:01 2026 +1000
interp_g7x: make the G7x roughing cycle independent of rounding
Discrete cases were decided by comparing floats that are meant to be
equal, and lathe profiles produce those ties by construction: an arc
starting at its own apex, an exactly flat facing cut, a scan line landing
on top of an arc. Moving the coordinates in tests/interp/g71-with-g70 by
a relative 1e-12, far below the 1e-6 tolerance the cycle works to, changed
the tool path in 16 of 20 runs and hung the interpreter in another 4.
Contracting a*b+c into an FMA is a much smaller disturbance than that,
which is why the test failed only on a compiler defaulting to x86-64-v3.
Those comparisons now carry the tolerance. The apex tie was the expensive
one: broken the wrong way, pocket() re-enters the same pocket forever,
which is the four hangs. add_distance() ends on the requested distance
rather than on an exact comparison against an accumulated sum, replacing
the stall guard from the previous commit.
The thresholds are plain numbers, so they only fit a part of a few tens of
millimetres; scaled up, the same perturbation broke the path at 190 mm and
every run at 305 mm. The profile is normalised into a canonical range on
entry and the tool path scaled back on output, by a power of two so the
scaling adds no rounding of its own and is 1 at the size the thresholds
were chosen for.
The tool path now survives that perturbation on parts from 0.4 mm to
381 m, and interp_g7x.o gives identical output built with
-march=x86-64-v3, -ffp-contract=off, -mfpmath=387, -O0 and -O3.
The two lines added to the g71-with-g70 expected output are the contour
segment at the flatness test, now climbed like the rest. Both are zero
length repeats of moves already present, so the path is unchanged.
commit d17b036e072ddaaa31ab77e4e1345a952a8bdb17
Merge: 54cd4d6b 72db1592
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Aug 29 02:40:06 2026 -0400
Merge pull request #4469 from BsAtHome/halgs_rm-halpr-function-access
hal: Stop exporting halpr_*() private functions and shared memory base
commit 54cd4d6b23d3496a9a3d7bc9ce7373e1e63f3e83
Merge: 0eb76c61 e59dc278
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Aug 29 02:39:25 2026 -0400
Merge pull request #4470 from BsAtHome/fix_docs-rm-hal-legacy
docs: Update HAL API documentation - remove legacy API docs
commit 0eb76c619dbe544a356fc548de817ca91492ca57
Merge: f3532938 ddd7e5ca
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Aug 29 02:37:12 2026 -0400
Merge pull request #4472 from BsAtHome/halgs_deprecate-old-api
hal: Deprecate old HAL API
commit 57c0b500486d45ff43310d3f25c1db06979cc419
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Aug 23 17:35:00 2026 +1000
tests: cover the frame helpers
Pins down the two properties the chapter is about.
Relating one tool axis convention to the other is a rotation, not a change of
sign: a negated third column is refused because it is a reflection, the
declared rotation post-multiplies so it is read in the module's own frame, the
half turn keeps tool x and reverses the other two, and applying it twice is
the identity. Also checks the pumakins zero pose, whose own frame is a half
turn about x, ends up as the identity after the declaration it makes.
And composing the two reported frames means transposing the work one:
toolFrameInWork() leaves the tool alone when nothing turns the work, gives a
proper rotation, and composes a work frame with its own inverse back to the
identity.
Verified by mutation rather than by passing: making TOOL_FRAME_FLANGE negate
only the tool axis fails nine checks, reversing the multiplication order fails
four, and dropping the transpose in toolFrameInWork() fails two.
Built the way tests/blendmath builds, compiling the source under test directly
with the rest garbage-collected by the linker.
commit e3eda9500870c2ac7bf0f187b3c424957822cb20
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Aug 23 17:09:31 2026 +1000
pumakins: supply the work and tool frames
The arm carries the tool and nothing carries the work, so the work frame is
the identity and this is the first module whose own tool maths is not in the
convention.
pumakins builds the ISO 9787 mechanical interface frame, whose z points
perpendicularly away from the flange, and it relies on that: it reaches the
tool tip by adding PUMA_D6 along the third column. So it answers in its own
frame and declares TOOL_FRAME_FLANGE, and switchkins turns it into the
convention. Nothing in the module itself flips a sign.
Lift the rotation out of the forward kinematics into pumaFlangeRotation()
rather than writing it twice, which is the whole point: a second copy of a
machine's geometry that has to be kept in step by hand is the thing this work
exists to remove. The block moves verbatim and the forward kinematics loses
the locals that went with it.
At every joint zero the module's own frame is diag(1, -1, -1), a half turn
about x, so after the declared half turn it reports the identity: tool axis
[0, 0, 1], tool x [1, 0, 0]. A puma at zero and a vertical mill at zero give
the same answer, which is right, because both have the tool pointing down at
the work.
commit b677195d8ecd47f10a42fea6e99376fb0e9bc44e
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Aug 23 15:29:34 2026 +1000
xyzacb_trsrn, xyzbca_trsrn: supply the work and tool frames
These are the machines the split is for: a rotary carries the work and two
more carry the tool, so neither frame is the identity and neither can be
recovered from their product.
The work frame is the table rotation, written in machine coordinates. The
tool frame is the primary rotation about z times the nutating secondary,
written as two matrices and multiplied rather than expanded, so it can be read
against the matrices in the config's remap_funcs_twp.py.
Identity kinematics leaves both square with the machine, and so does tool
kinematics: there the world axes are the tool axes by construction, which is
what makes a G1 Z move run along the tool, so there is no machine-relative
frame to report.
Checked against the forward transform of each module at 27 poses. The
coefficients the forward applies to a displacement of the linear joints are
the transpose of the work frame alone, as they should be, since turning the
head does not move the tool tip when a linear joint moves. The tool axis,
recovered separately as the direction the tip retreats along when the tool
gets longer, matches the third column of transpose(work) * tool. For tool
kinematics the same coefficients come out as the transpose of the whole chain
including the virtual rotation, which is the statement that the world frame is
the tool frame. Agreement is to 3e-9 throughout.
commit a6ea5b12932af68e84e224c6916ee8e3257f494d
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Aug 23 15:29:33 2026 +1000
trivkins: supply the work and tool frames
trivkins does not build on switchkins.c, so it does not pick up the identity
frames the way a switchkins identity type does. Hand them through, since it
is the kinematics most machines run and a caller that has to special-case the
commonest module has not gained much.
commit b6b8ef5fbfad70e4e30c96c922028451da51dec9
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Aug 23 15:24:40 2026 +1000
trtfuncs: supply the work and tool frames for xyzac and xyzbc
Both rotaries carry the work on these machines, so the tool never turns in the
machine frame and its frame is the identity. All the rotation is the work's.
The forward transform already contains it: the coefficients it applies to a
displacement of the X, Y and Z joints are the rotation from machine into work,
so the work frame in machine coordinates is their transpose.
Checked against the forward transform by central difference over the linear
joints at four primary and four secondary angles with both settings of
conventional-directions: the composition transpose(work) * tool reproduces the
frame to 3e-9, the result is orthonormal with determinant one, and the tool
axis is machine z with the rotaries at zero.
The check also shows the sign question plainly. With conventional-directions
true, A at 90 degrees on an xyzac machine puts the tool axis along -Y in work
coordinates, which is +Z turned counterclockwise about +X as the documentation
says it should be. With the pin at its default of false the same move puts it
along +Y.
commit 4be34b5c0ae2df73d5734b006a03eb20ba2045fa
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Aug 23 15:24:15 2026 +1000
kinematics: add optional work frame and tool frame entry points
kinematicsForward() reports where the controlled point is and nothing about
which way anything faces, so a consumer that needs the geometry rebuilds it
for itself. Add two entry points a module can answer with instead:
int kinematicsToolFrame(const double *joint, PmRotationMatrix *rot,
const KINEMATICS_FORWARD_FLAGS *fflags);
int kinematicsWorkFrame(const double *joint, PmRotationMatrix *rot,
const KINEMATICS_FORWARD_FLAGS *fflags);
Each returns the columns of that frame's axes in machine coordinates.
Conventions are in the Kinematics Conventions chapter.
They are reported separately rather than as the single work-to-tool rotation
because the product cannot be taken apart again. A consumer that has to place
both bodies, a simulation model or a tracking display, needs each against
something that does not move; one that wants the tool in workpiece
coordinates, which is what a tilted work plane asks for, composes them with
toolFrameInWork(). Composing is a multiply, decomposing is impossible, so the
halves are what the module owes the caller.
Modules built on switchkins.c export both and dispatch on the current type,
returning -1 for a type that has not supplied them. A type registers with
switchkinsRegisterFrames() from its switchkinsSetup(); leaving it out costs
nothing. Adding it that way rather than as arguments to switchkinsSetup() and
switchkinsRegister() keeps both signatures as they are, so no module has to
change to build.
The tool frame has two live conventions, so a type also declares the rotation
relating its own to the one in use, and the dispatch applies it. That is a
rotation and not a sign: negating the third column alone leaves determinant
-1, a reflection. It is checked once at registration rather than on each
call. The work frame needs none of this, having no tool axis to point the
wrong way.
Identity types answer both the same way whichever module asked for them, so
switchkins.c attaches the identity pair to any type whose forward is the
identity one, and every switchkins module gains correct frames for its
identity type without being touched.
Nothing in motion calls either, so no module is obliged to define them and a
module outside the tree need not know they exist.
commit 9e97f59294e40225693d9df8fcd1e3cb5ee2ace1
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sun Aug 23 14:32:38 2026 +1000
docs: add a kinematics conventions chapter
A kinematics module reports the controlled point and nothing else, so
everything needing the rest of the machine geometry rebuilds it. For
xyzacb-trsrn the same chain is written three times: closed-form in
xyzacb_trsrn.comp, as homogeneous matrices in the config's
remap_funcs_twp.py, and as signed HalRotate calls in the vismach model. The
Python copy is kept in step by a comment saying its matrices "must be the
same as the ones used to derive the kinematic model".
Write down the vocabulary they would need to share: the four frames and which
one kinematicsForward() reports in, the rotation sense already stated under
Rotational Axes and its ISO 841 equivalent, what conventional-directions
costs at its default, and the definition of the tool frame.
Tool x is the part worth stating as a rule rather than a formula. The
virtual rotation about tool z supplies what a five-axis machine cannot, and
the convention is that it leaves tool x parallel to the machine xy-plane; the
formula follows from the machine's own secondary rotation matrix, which is
why the two nutating configs in tree have different ones.
Also anchor the Rotational Axes section so it can be referenced.
commit f35329387d4baeb2491862b0af607793fbda071b
Merge: 49660cb6 455ef16d
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Sat Aug 29 01:04:35 2026 -0400
Merge pull request #4483 from BsAtHome/fix_mb2hal-modinfo
mb2hal: Fix module info placement and cppcheck problem
commit 455ef16db01c82f8c7ec3a50d64038a48018f4ac
Author: Bertho Stultiens <bertho@vagrearg.org>
Date: Fri Aug 28 14:26:05 2026 +0200
mb2hal: Fix module info placement and cppcheck problem.
commit 49660cb6439326da1e31664bfde436633223030e
Merge: d47bccc9 3570f8ab
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Fri Aug 28 08:43:25 2026 -0400
Merge pull request #4479 from weblate/weblate-linuxcnc-linuxcnc-docs
Translations update from Hosted Weblate
commit 25398de1c003433ccfee455d6c48be6641fb6dcf
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Fri Aug 28 11:01:08 2026 +0800
interp_g7x: build with -ffp-contract=off, fix latent geometry bugs
The g7x offsetting code takes discrete threshold branches on iterated
floating-point values (segment deletion at radius<1e-3, monotonicity,
arc insertion at gap>1e-2), so a 1-ulp rounding difference can flip a
branch and diverge the whole toolpath. GCC defaults to
-ffp-contract=fast; when targeting x86-64-v3 (ubuntu-26.04 CI runner
gcc default, --with-arch-64=x86-64-v3) this emits FMA instructions and
changes rounding, failing g71-with-g70 and g71-endless-loop_2 in CI.
Verified: rebuilding only interp_g7x.o with -march=x86-64-v3 fails,
-ffp-contract=off passes; -O0/-O2/-O3/arch without FMA are all
byte-identical, so contraction is the only variable.
Disable FP contraction for interp_g7x.o (same semantics as ISO C's
default). Investigating the divergence also exposed latent bugs that
the flipped branches merely reach:
- erase(p--) on a list iterator at begin() is undefined behavior; in
practice it ends the loop early, skipping offsets for all remaining
segments. Use the p=erase(p) idiom (two sites).
- round_segment::intersect_end(round_segment*) silently clamped
|cosB|>1 (non-intersecting circles) and set p's end to a point on
the wrong circle, producing arcs the interpreter itself rejects.
Trim to the closest points on the line of centers instead.
- the add_distance() accumulation loop requires exact FP equality;
under some roundings the step becomes too small to change the sum
and the loop never terminates. Break when the sum stops changing.
- the add_distance() junction snap moves arc endpoints off their
circle; refuse to snap across a gap larger than 1e-3 instead of
manufacturing an invalid arc.
All fixes keep byte-identical output on the g71 tests with the
baseline arch; they only change behavior in cases that previously
produced undefined or geometrically invalid results.
commit 3570f8abff58db91c41b5fefe5950686b3bb4018
Author: Luca Toniolo <toniolo.luca@outlook.com>
Date: Thu Aug 27 17:25:57 2026 +0200
Translated using Weblate (Tamil)
Currently translated at 81.4% (27681 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Translated using Weblate (Tamil)
Currently translated at 81.4% (27680 of 33994 strings)
Author: Luca Toniolo <toniolo.luca@outlook.com>
Co-authored-by: Luca Toniolo <toniolo.luca@outlook.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/ta/
Translation: LinuxCNC/LinuxCNC Documentation
commit 44a5145664132048a301a1f0ccf8c2680bc8f3f0
Author: Salvador Peña <salvadorp74@hotmail.com>
Date: Thu Aug 27 17:25:56 2026 +0200
Translated using Weblate (Spanish)
Currently translated at 34.7% (11801 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Translated using Weblate (Spanish)
Currently translated at 34.7% (11797 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Translated using Weblate (Spanish)
Currently translated at 34.6% (11792 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Co-authored-by: Salvador Peña <salvadorp74@hotmail.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translation: LinuxCNC/LinuxCNC Documentation
commit 2ad450b9038fde5bf502cce12b2dffbf74077552
Author: Alexey Presnyakov <309782758+alex-pres@users.noreply.github.com>
Date: Wed Aug 26 18:50:58 2026 +0400
preview: draw stock outlines from (WORKPIECE,...) comments
A (WORKPIECE,BOX|CYLINDER|TUBE,...) comment declares the stock the program is cut
from; every preview host draws it as a translucent wireframe, toggled per host,
and get_workpieces() hands a GUI the declared params and the outline in machine
coordinates. Program extents are unchanged.
commit d47bccc94a40852ca04dadb3f062f709e95a651c
Merge: b7a619bc bdb13f66
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date: Wed Aug 26 21:50:14 2026 -0400
Merge pull request #4478 from weblate/weblate-linuxcnc-linuxcnc-docs
Translations update from Hosted Weblate
commit bdb13f66b3c8c86f25f36306ff63cdcc3183358b
Author: Salvador Peña <salvadorp74@hotmail.com>
Date: Thu Aug 27 00:34:47 2026 +0200
Translated using Weblate (Spanish)
Currently translated at 34.5% (11758 of 33994 strings)
Author: Salvador Peña <salvadorp74@hotmail.com>
Co-authored-by: Salvador Peña <salvadorp74@hotmail.com>
Translate-URL: https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/es/
Translation: LinuxCNC/LinuxCNC Documentation
![[bug history graph]](https://qa.debian.org/data/bts/graphs/l/linuxcnc.png){kind=link}