Debian Package Tracker
Register | Log in
Subscribe

linuxcnc

Choose email to subscribe with

general
  • source: linuxcnc (main)
  • version: 1:2.9.9-2
  • maintainer: LinuxCNC Developers (DMD)
  • uploaders: Petter Reinholdtsen (DMD) – Sebastian Kuzminsky (DMD) – Jeff Epler (DMD) – Andy Pugh (DMD)
  • arch: all any
  • std-ver: 4.7.4
  • VCS: Git (Browse, QA)
versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]
[pool directory]
  • oldstable: 2.9.0~pre1+git20230208.f1270d6ed7-1+deb12u2
  • old-p-u: 2.9.0~pre1+git20230208.f1270d6ed7-1+deb12u2
  • stable: 1:2.9.4-2+deb13u1
  • unstable: 1:2.9.9-2
versioned links
  • 2.9.0~pre1+git20230208.f1270d6ed7-1+deb12u2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
  • 1:2.9.4-2+deb13u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
  • 1:2.9.9-2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
binaries
  • linuxcnc-doc-de
  • linuxcnc-doc-en
  • linuxcnc-doc-es
  • linuxcnc-doc-fr
  • linuxcnc-doc-zh-cn
  • linuxcnc-uspace (3 bugs: 1, 1, 1, 0)
  • linuxcnc-uspace-dev
action needed
Debci reports failed tests high
  • unstable: pass (log)
    The tests ran in 0:03:16
    Last run: 2026-09-25T07:28:45.000Z
    Previous status: unknown

  • testing: fail (log)
    The tests ran in 0:00:18
    Last run: 2026-01-31T13:46:36.000Z
    Previous status: unknown

  • stable: pass (log)
    The tests ran in 0:01:33
    Last run: 2026-07-15T20:01:47.000Z
    Previous status: unknown

Created: 2026-01-31 Last update: 2026-11-12 02:03
A new upstream version is available: 2.9.10 high
A new upstream version 2.9.10 is available, you should consider packaging it.
Created: 2026-10-23 Last update: 2026-11-12 00:00
lintian reports 1 error and 55 warnings high
Lintian reports 1 error and 55 warnings about this package. You should make the package lintian clean getting rid of them.
Created: 2026-06-30 Last update: 2026-06-30 09:17
The package has not entered testing even though the delay is over normal
The package has not entered testing even though the 2-day delay is over. Check why.
Created: 2026-07-04 Last update: 2026-11-12 02:01
1 bug with a patch to review in the bug tracker normal
The bug tracker contains patches fixing 1 bug to review: include them, or remove the patch tag.
Created: 2026-09-02 Last update: 2026-11-12 02:00
version in VCS is newer than in repository, is it time to upload? normal
vcswatch reports that this package seems to have a new changelog entry (version 1:2.10.0~pre2, 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 21519b42d3b72d8871145e8f2735bba267bca6be
Merge: 8b052660 8cbca907
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 11 22:45:19 2026 +0100

    Merge pull request #4823 from rene-dev/halui-max-velocity
    
    halui: read the max-velocity limit from the INI file again

commit 8b0526601b77bb02e107a1c62f10694cb7115e2c
Merge: c4f63177 858fad3b
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 11 22:44:00 2026 +0100

    Merge pull request #4826 from rene-dev/preview-pocket-numbers
    
    preview: #<_selected_pocket> and #<_current_pocket> read -1

commit 858fad3b21845590da19c136d5b6ca7973e4e71d
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 11 22:42:43 2026 +0100

    status: send a tool entry's pocket number and orientation
    
    CANON_TOOL_TABLE_update() left out pocketno, orientation and comment, so
    a reader of the status over the network, through the NML server, got 0
    for the orientation and the pocket number of stat.loaded_tool. A reader
    on the machine itself reads the status from shared memory and was not
    affected.
    
    All fields of the entry are sent now.

commit fe5b2a4505dbf6f16bb9e969cb66e510eed7c77b
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 11 02:18:50 2026 +0100

    preview: #<_selected_pocket> and #<_current_pocket> read -1
    
    On a non-random tool changer the two parameters are the pocket number of
    the tool's tool table entry. The preview fills the interpreter's tool
    table from the canon's get_tool() tuple, which had no pocket number, so
    both read -1 there. A tool change remap that moves to a position worked
    out from the pocket, like configs/sim/axis/remap/rack-toolchange, was
    drawn in the wrong place, and could report a move beyond the machine's
    limits that the run then did not make.
    
    stat.tool_table entries get the pocket number as a 15th field, pocketno,
    and get_tool() may return it as a 15th item. StatMixin hands the entries
    on as they are, so the previews built on it need no change. A canon that
    returns 14 items works as before.
    
    Fixes #4813

commit c4f631773873df232bbf5c320b6e9b6142bb0e6a
Merge: 64fab5d4 7412d9db
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 11 21:39:43 2026 +0100

    Merge pull request #4827 from rene-dev/stat-loaded-tool
    
    status: the loaded tool's entry as stat.loaded_tool

commit 7412d9db7349156617139395e5b246dcc39ed9b7
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 11 03:06:47 2026 +0100

    status: the loaded tool's entry as stat.loaded_tool
    
    The GUIs took the loaded tool's data from stat.tool_table[0], which reads
    the tool mmap and relies on the spindle's entry being first. The status
    message has carried that entry all along, as toolTableCurrent, but nothing
    read it apart from tool_watch.
    
    Expose it as linuxcnc.stat.loaded_tool and use it in AXIS, gmoccapy,
    hal_glib, gremlin and the vismach millturn and 3axis-tutorial models. The
    two vismach models indexed the tool table with the tool number, which
    only gave the loaded tool when its number matched its position.
    
    halui takes the loaded tool's diameter from the status too. It no longer
    attaches the tool mmap or links libtooldata, and a loaded tool that is not
    in the tool table now gives a diameter of 0, where the pin kept its old
    value.
    
    toolTableCurrent was only written when something stored the spindle's
    entry. A reloaded tool table clears that entry without storing it, so
    with the loaded tool gone from the table the status kept the old tool's
    data. Task now copies the entry into the status after a tool change, a
    changed offset and a reload. The field is also part of the NML update, so
    it reaches a remote status reader, and it exists in the TOOL_NML build.

commit 8cbca907584e656897fade964d9738808fbf4b63
Author: Rene Hopf <renehopf@mac.com>
Date:   Tue Nov 10 16:06:10 2026 +0100

    halui: read the max-velocity limit from the INI file again
    
    The conversion to the new INI parser kept the condition but dropped the
    read, so maxMaxVelocity stayed 1 and halui.max-velocity.* could never
    set more than 1 unit/s. Read [TRAJ]MAX_LINEAR_VELOCITY, falling back to
    [AXIS_X]MAX_VELOCITY and then 1.0, as before.

commit 64fab5d412498f68c5730088178202da37d1d2fd
Merge: 824b95da 7f881634
Author: Rene Hopf <renehopf@mac.com>
Date:   Tue Nov 10 13:32:20 2026 +0100

    Merge pull request #4809 from grandixximo/ilowpass-deprecate
    
    ilowpass: deprecate, smooth wheel jogs with jog-accel-fraction

commit 824b95da7c29816bb6cf1f3221c2ded99b9b56ca
Merge: cc3097b8 be52eb3a
Author: Rene Hopf <renehopf@mac.com>
Date:   Tue Nov 10 13:21:18 2026 +0100

    Merge pull request #4814 from rene-dev/remove-tool-prep-index
    
    iocontrol: remove the tool-prep-index pin

commit be52eb3a308c57340d4d5cd206ad36563dd5bd2f
Author: Rene Hopf <renehopf@mac.com>
Date:   Mon Nov 9 17:00:04 2026 +0100

    iocontrol: remove the tool-prep-index pin
    
    iocontrol.0.tool-prep-index carried the prepared tool's position in
    LinuxCNC's internal copy of the tool table. On a non-random changer
    that is just the order the tools were loaded in, which means nothing
    outside LinuxCNC; tool-prep-number and tool-prep-pocket give the tool
    and its pocket.
    
    Task also used the pin to remember which tool it was preparing between
    emcToolPrepare() and the changer's tool-prepared, reading its own output
    back. That now lives in Task itself.
    
    The db_demo panel stops showing the pin, and the io(1) man page and the
    toolchanger section of the tool compensation docs stop describing the
    internal index.

commit 7f8816340d9af8a52f3cbdf044a5750856fc7e2a
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 23:41:02 2026 +1100

    ilowpass: deprecate in favour of jog-accel-fraction
    
    No in-tree config uses ilowpass any more. Point its man page and the
    component list at jog-accel-fraction, so it can be removed a release
    later.

commit 75b7dc5e373ca53e258a4b4eec35fe475012a431
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 17:12:37 2026 +1100

    configs, docs: smooth wheel jogs with jog-accel-fraction, not ilowpass
    
    Motion plans wheel jogs itself under the axis and joint limits, and
    jog-accel-fraction lowers the acceleration of wheel jogs. With
    PLANNER_TYPE = 1 and a MAX_JERK they are also jerk limited. ilowpass in
    front of jog-counts only adds a lag after the wheel stops and defeats
    jog-vel-mode, as motion never sees the wheel stop.
    
    The pico pendants, shuttle.hal, the touchy example and the MPG example
    now feed the counts straight to jog-counts and set jog-accel-fraction to
    0.25. The jog scales grow by the ilowpass scale they no longer divide.
    The scorbot-er-3 INI pointed at a shuttlexpress.hal that does not exist;
    it is shuttle.hal.

commit cc3097b85748bec7e1ff801cd1aaf5fa33052028
Merge: 53b93f4c c12aa641
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 21:06:22 2026 +0800

    Merge pull request #4808 from BsAtHome/hal64_iocontrol
    
    hal: Update iocontrol to 64-bit clean operation

commit 53b93f4cf2c9f78f2efb726569166a8a8a2de022
Merge: d73d2b61 12935bdb
Author: BsAtHome <bertho@vagrearg.org>
Date:   Mon Nov 9 13:48:40 2026 +0100

    Merge pull request #4807 from grandixximo/twp-tests-fast
    
    tests: bring the multiaxis tests from #4730 under 10 seconds each

commit 12935bdba3b57fc3cf3de5f8316464219d556c6a
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 22:19:00 2026 +1100

    tests: bring the multiaxis tests from #4730 under 10 seconds each
    
    Issue #4805 (BsAtHome): twp-table took over five minutes and twp-native over one, and with ptp-machine-frame, ptp-robot and kins-switch at 16 to 26 seconds they added about eight minutes to CI. None of them waits on anything but motion and polling: the sims moved at 90 deg/s on the rotaries and 120 mm/s on the slides, often under TCP, where the slides swing around a pivot to keep the tip still; and every step waited out a 10 ms task cycle, the 10 ms poll of wait_complete() and two 50 ms status polls.
    
    The sims now move fast. Most checks look only at where a move ends. twp-native reads paths from a sampler once a servo cycle: its G30.5 check now allows the a * dt^2 / 2 the turn can fall short between two samples from the joint's own acceleration, where it had the figure for 700 mm/s^2 written in. kins-switch samples status while its program strokes W, and W rests on a dwell at the end of the stroke.
    
    The tests wait on what wait_complete() waits for, polled every 2 ms, and twp-native, twp-table and the ptp tests run task on a 1 ms cycle. Faster polls showed three races the slow ones had hidden. A move counted as ended when motion was in position with an empty queue, which is also true before task has sent the move on: the tests now also wait for task's interpreter to be idle. Status is a copy task writes once a cycle, so two polls can read the same copy and see still joints that are moving: a move now counts as ended only on a copy task wrote two cycles after the command, and still joints only over copies with motion's heartbeat apart. And twp-native counted the sampler log's lines before a move while the log, block buffered, could still lack the end of the previous one: it now waits for the log to reach the machine at rest before a move as well as after, and reads only the lines added since.
    
    kins-switch keeps its 10 ms task cycle. At 1 ms its program's G12.1 after a G0 W0 sometimes switches while W is still about 25 um from the end of its move, and W stays there; that is for its own issue, not for this test.
    
    Two tests are split, so that each half starts LinuxCNC once and runs beside the other: twp-table-one-sided takes the one-sided A of twp-table's second run, and twp-native-ptp the point-to-point moves of twp-native, sharing its INI and HAL files and, through twp-native/native.py, its helpers. twp-table starts each case with one joint-space G69 G53.5 move rather than a G0 of the tip, since G53.1 chooses its pose from the rotaries alone; it checks the pose with no P against the P1 and P2 poses it already has from the same start rather than driving there again; and it keeps three planes of five, one in general position, one with J negative and one whose C sits near the +-180 wrap. twp-native's timed point-to-point feeds take half a second each rather than one and two.
    
    Here, each alone:
    
      twp-native            70 s  =>  7.1 s
      twp-native-ptp                  7.2 s
      twp-table            338 s  =>  9.0 s
      twp-table-one-sided             4.1 s
      ptp-machine-frame     26 s  =>  5.5 s
      ptp-robot             22 s  =>  4.2 s
      kins-switch           16 s  =>  8.4 s
    
    All of them pass with six copies of each running beside four busy loops, and pinned to one CPU. About 3.6 s of each is LinuxCNC starting and stopping.
    
    Fixes #4805

commit c12aa641c285bdc8df3a8f22aee13ff2ee9f0766
Author: Bertho Stultiens <bertho@vagrearg.org>
Date:   Mon Nov 9 13:07:18 2026 +0100

    hal: Update iocontrol to 64-bit clean operation

commit d73d2b6133b4dfd8858bc23d38bc4738a5335e82
Merge: 9acc932d 99f22443
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 19:13:34 2026 +0800

    Merge pull request #4796 from BsAtHome/hal64_ilowpass
    
    hal: Update ilowpass and tests to use 64-bit clean operation

commit 9acc932db638d78a6aeee513024b064a91fa56c9
Merge: 770b59e0 2aaa6bcf
Author: BsAtHome <bertho@vagrearg.org>
Date:   Mon Nov 9 10:32:41 2026 +0100

    Merge pull request #4804 from grandixximo/axis-jog-counts-sint
    
    motion: read the 64-bit axis jog-counts without truncating

commit 770b59e047269b59d314d61702c6cb2138568246
Merge: 08ac9b35 22c99b46
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 14:41:22 2026 +0800

    Merge pull request #4730 from grandixximo/robot-machine-frame
    
    interp, motion: the point-to-point moves and the tool orientation codes, G53.1 to G53.7 and G68.3

commit 08ac9b350009eef661c7ef16f9955973dcbd7b13
Merge: 9262011a 84a208c6
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 14:32:09 2026 +0800

    Merge pull request #4794 from 85vmh/tp-threading-jerk-oscillation
    
    tp: run position-synchronized moves trapezoidal with the S-curve planner

commit 2aaa6bcf63660fa3f413c35ef84733672413d693
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 17:16:31 2026 +1100

    motion: read the 64-bit axis jog-counts without truncating
    
    axis.L.jog-counts is a SINT pin, but the wheel jog read it with
    hal_get_si32() while the previous count and the delta are 64-bit. When
    the counts crossed 2^31 the delta came out near -2^32 for one cycle: the
    target fell outside the limits and the jog was dropped, or with
    jog-vel-mode the axis ran back by its stopping distance. The joint wheel
    jog already reads its counts with hal_get_sint().
    
    The jogwheel-axis test now jogs across 2^31.

commit 9262011a0ac3e2ae5f6e3358c92a5ff5e28cd069
Merge: 13f12527 aeff4320
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 13:38:18 2026 +0800

    Merge pull request #4799 from grandixximo/docs-axis-letter-anchor
    
    docs: fix the ROTARY_MODULO link anchor in m-code

commit 13f1252777ca5aeb75fa1a3aba0ef2d6bcc15d0e
Merge: 4dcda01c c8011fa2
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 13:37:33 2026 +0800

    Merge pull request #4800 from grandixximo/weblate-docs-merge
    
    Merge Weblate linuxcnc-docs to unstick the docs component

commit c8011fa25c45d60b07042393c7740380c6f4f2b4
Merge: 4dcda01c ed20f62b
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 15:21:19 2026 +1100

    Merge Weblate linuxcnc-docs into master
    
    # Conflicts:
    #       docs/po/es.po

commit aeff43200a1168a735dfb639564f8c531c82632c
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 15:17:39 2026 +1100

    docs: point the ROTARY_MODULO link in m-code at the [AXIS_<letter>] anchor
    
    7573ef16d6 linked sub:ini:sec:axis_l, which does not exist; the section
    anchor in ini-config.adoc is sub:ini:sec:axis-letter. htmlcheck flagged
    the broken fragment on m-code.html in every language.

commit 22c99b46e39a78386d1d00c25762900fedba442b
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sat Sep 19 13:17:01 2026 +1000

    genserkins, pumakins: declare the arm kinematics the machine frame
    
    A robot's working transform reports the flange in the base frame, ABB's tool0 and KUKA's $NULLFRAME: the tool is applied on top by the interpreter, not by the maths, so the type G43.4 switches to is also the machine with the tool left out, the frame G13.1 and G49 cancel to and G53.5 moves in. pumakins and genserkins declare that one type both primary and machine. G13.1 and G49 leave a robot on its arm kinematics, where a robot controller leaves it, and the identity type, joints as axes, is reached by number; G53.5 moves the flange along a base axis and holds the rest, the orientation included, interpolated in joint space, and G28.5 and G30.5 with it. A machine frame type does not read the tool offset in the parameter block, so a module whose working transform does read it declares a type without it.
    
    The machine frame is described as the frame with the tool left out rather than with the orientation left out, since on a robot the rotary letters are the flange angles the module reports, not joints; the G13.1, G49 and G43.4 descriptions say machine frame where they said identity. tests/ptp-robot checks that G53.5 moves the flange from the arm kinematics and from the identity alike, and that G13.1, G43.4 and G49 all leave the robot on the arm kinematics, in place of the refusal it checked before.

commit c39f0d117d834b5aaf14204a4c3bfa7d65f874b0
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Oct 18 18:37:06 2026 +1100

    configs: the five axis sims move G53, G28 and G30 in the machine frame
    
    The bridgemill, table-dual-rotary, table-rotary-tilting and both table-rotary_spindle-rotary-nutating sims set MACHINE_MOVES_IN_MACHINE_FRAME, with a comment saying what it does, so a new user starting from one gets G53, G28 and G30 that put the slides in the same place whatever the tool and the head angle, and anyone copying the config sees the setting and where it is documented. None of their programs or remaps uses those codes under the TCP kinematics: the boat demo's G53 lines carry G49 or follow it, which cancels to the machine frame kinematics first.
    
    The G43.4 section and the switchable kinematics chapter now point at the setting too, where someone setting up a TCP machine reads.

commit c0130bef4bf4a2576f43763eaf50bec0b35b296d
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Oct 14 00:51:37 2026 +1100

    preview: read the machine moves on the kinematics type the machine is on
    
    With [RS274NGC] MACHINE_MOVES_IN_MACHINE_FRAME set, a GUI's preview read every G53 in the machine frame whatever type the machine was on, the GUI's own first. A GUI starts its preview by restating where the machine stands, with G53 G0 to the position in the status buffer: a block per axis in AXIS, one block in the other screens. The preview could not tell which kinematics type was in force, since its canon answered type 0 and no flags for every type, so it ran on type 0 and the decision fell back on the machine's kinematics type, which for a switchable module is never the identity.
    
    The status buffer carries the type motion runs and what the module declares each type to be, as the interpreter in task reads them. The Python status now reports them as kins_type and kins_type_flags, with the KINSTYPE_ constants, and the status mixin the preview canons are built on hands them to the preview, read once a parse because the interpreter asks for the flags on every block. The preview then starts on the type the machine is on and follows the program's G12.1, G13.1, G43.4 and G49 as the interpreter in task does, so a program's G53, G28 and G30 land where running it would land them. A canon with no machine to ask answers as before.
    
    The restating codes are a different matter whenever the machine stands on another type than the machine frame, under a tool centre point type say: the position they restate is in the world of that type, and G53 is the only way to say it. They are the GUI's codes, not the program's, so the preview holds the option off until the program starts.
    
    The preview also kept the tool offset the last parse ended on, which the interpreter reads as it starts. AXIS restates the offset after the position, and under a tool centre point type with the tool tilted the restated G53 depends on the offset in force, so two previews of the same program could start apart. Each parse now starts with no offset, which the GUI's restating codes then set.
    
    The ptp-machine-frame test previews a program with a G53 through both forms of the restating codes, AXIS's with the tool offset in force, which under the tip type the kinematics evaluates in the GUI's own process, on the machine frame type, under the tip type and on the plain identity, and one that selects the machine frame type with G13.1 before its G53 under the tip, and checks that each ends where the same program with G53.5 does. A move that goes nowhere reads back the restated position, which has to be the one the machine reports, and on the plain identity the preview has to end where running the program ends. Without the type from the status buffer the run check fails, without the hold the restated position does, and without the offset reset the second preview under the tip starts elsewhere.
    
    Reported by Sigma1912.

commit e9b6b07590b62b0745d5d6503ad8484fe4e209f3
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Fri Sep 18 22:50:06 2026 +1000

    interp: G28.5 and G30.5, the machine frame forms of G28 and G30, and MACHINE_MOVES_IN_MACHINE_FRAME
    
    G53, G28 and G30 move in the world of the kinematics in force with the offsets removed, and on a table-side kinematics that world turns with the table: G53 X0 Y0 Z0 under TCP with the table at A10 takes the tool tip to the turned origin, which the slides reach elsewhere. Under a tool centre point kinematics G53 also takes the tool length off along machine Z, where the kinematics carries it along the tool, so with the tool tilted the slides land where the tool and the head angle put them. That is what the existing switchkins configs rely on, so it stays; the G53 section says so now, and points at G53.5 for the machine frame.
    
    G28.5 and G30.5 are to G28 and G30 what G53.5 is to G53: the stored position is read in the machine frame with the orientation left out, the way G53.5 reads its words, the slides on a machine whose slides line up with its frame, and the move is a joint-space traverse there, with no offset, tool length or work plane. Axis words on the line are a machine frame waypoint, and then only those letters go to their stored values, as G28 does with its words. The stored position has to be saved on the machine frame type, where the world is that frame, or with the option below.
    
    [RS274NGC] MACHINE_MOVES_IN_MACHINE_FRAME, off by default, is for a configuration that wants the machine codes to mean that frame: whenever the kinematics in force is not the machine frame type, G53, G28 and G30 run as G53.5, G28.5 and G30.5, and G28.1 and G30.1 store the machine frame position those read back. The slides then go to the words or the stored position whatever the tool, the head and the table are doing. The codes are swapped as the block is read, so the checks and the errors are the machine frame codes'. The decision is the flags the module declares for the selected type, with the machine's kinematics type as the fallback for a module that switches nothing; a plain identity type that is not the machine frame is read in the machine frame like any other, and on the machine frame type G53 stays a straight move.
    
    The letter mapping and the joint move come out of convert_ptp_joints into slide_joints and ptp_joint_move, shared by the three codes, and the check that each letter names joints of its own unit class into letters_name_joints, which the store shares. The twp-native test stores a position on the identity, checks G28.5 and G30.5 with the head tilted under TCP, the waypoint included, sets the option and checks that under TCP G53 lands where G53.5 does on one joint-space move, that G28 and G30 go back to the slides G28.1 and G30.1 stored with the head tilted, and that on the identity the codes are the world's. The ptp-machine-frame test does the same on the slanted module, where G28.5 with the head tilted lands the carriage, and checks the option under the tip and under the plain identity, where G53 Y10 holds machine X. The waypoint check wants the joint to reach its turn, and a status snapshot per task cycle misses a turn by up to 9e-3 mm at the test's deceleration, which failed on a loaded runner: the twp-native test now reads the path of every move from a sampler on the servo thread, logged by halsampler, where the turn falls inside one cycle.

commit 2b7cda418ba8b3632aebe825280cdeb11916a492
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Sep 15 15:58:17 2026 +1000

    interp: G43.5, the tool axis as a vector
    
    G43.5 is G43.4 with one thing more: while it is in effect a G0 or G1 line may give the tool axis as I J K in place of rotary words, the form of a five-axis program written for the tool rather than the machine, Fanuc's tool center point control type 2. The rotaries are solved through the module's tool frame inverse, the solver G53.1 uses, split out as orient_solve(): every orienting joint free, the pose nearest the present one, so a path of vectors runs continuous; on the pole of the primary rotary the free joint stays. The pose enters the move as program rotary words through machine_pose_to_program(), so rotary offsets are right by construction and the move interpolates like any other. The vector is read in the coordinate system the line's X Y Z are in, the tilted plane where one is active, the machine's on a G53 line. A direction is never incremental, so G91 applies to the axis words only, and I J K alone turns the tool in place. No configuration names the rotaries: the same program orients a head, a table and a robot.
    
    Refused: a vector with a rotary word, a zero vector, the identity kinematics, a vector on a G53.5 or G53.7 line. Left out: Fanuc's interpolation of the vector between lines, which needs the kinematics inside the planner. The semantics follow the G43.5 greatEndian built for xyzab_tdr_kins on the fork, including that the vector is absolute under G91; this is the generic form.
    
    tests/kins-switch covers the vector against rotary words, G91, the pole, a rotary offset and the refusals; docs in g-code.adoc.

commit 516dbcf42d38feff92ebd4ff6b5c8a996d5e8a2b
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Oct 13 22:04:43 2026 +1100

    kinematics: an offset across the tool turns with the tool
    
    The X and Y of a tool offset, a tool held off the spindle axis, stayed
    on the work axes under every kinematics.  Canon adds the whole offset
    along them; a module that applies the tool takes the length back off
    and applies it along the tool axis, but leaves X and Y where canon put
    them.  With the head or the table turned the tip landed off the
    programmed point by (I - R)(x, y, 0), R the tool frame in work
    coordinates: on 5axiskins at B-22.5 C45 a 4, 3 offset put it 4.2 mm
    off.
    
    The offset is the tool's own, given against the machine with the
    rotaries at zero, so the shared code turns X and Y with the tool frame
    the module reports.  kinsOpsForward() adds (I - R)(x, y, 0) to the pose
    the maths answers, kinsOpsInverse() takes it off the pose it hands the
    maths, settled on the joints the inverse finds, and kinsOpsJacobian()
    adds the term the turn contributes.  Realtime and the loader make the
    same calls, so motion, the interpreter's prediction of a tool offset
    change and the segment cap agree.  Nothing is turned without an X or Y,
    on a type flagged identity or machine, which leave the tool out of
    their maths, or for a module that reports no tool frame (scorbot-kins,
    genhexkins, pentakins), where X and Y stay on the work
    axes as before.
    
    tests/kins-params evaluates 5axiskins, the trt modules and the trsrn
    modules under a 4, 3 offset across the tool, the same in realtime and
    through the loader, and checks that each module's length lies along its
    own tool axis, that the tip is the point the tool hangs from less the
    offset turned with the tool, and the Jacobian against differences of
    the inverse.  tests/kins-switch puts the tip on a programmed point
    through motion with the head tilted.  Both fail without the change.
    
    Reported by Sigma1912.

commit b01edecea6aae10d9f72b4f7d9869ebf252a4422
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Sep 14 15:37:46 2026 +1000

    motion, interp: a tool offset change under a tilt keeps the joints
    
    A module that applies the tool length itself reads it from motion, so a G43 with the head tilted moves the programmed point, not the joints; motion, task and the interpreter each did something else. Motion re-reads the point from the joints under the new tool, as after a kinematics switch, takes the external offsets off, moves the planner onto it and latches the joint hold there. The interpreter predicts the same point through the loader, from the joints the machine stands on, or for a G43.4 that switches on the same line from the joints read in the old kinematics before the switch, evaluating with the tool offset the program is under rather than the one motion has reached; the point rides along with the offset on EMC_TRAJ_SET_OFFSET, and motion aborts when its own answer differs. Under the identity, and where the module cannot be evaluated, the interpreter shifts by the offset difference as before and motion aborts only if the point moved. Task issues the offset once the queue has drained, so no queue busting is needed.
    
    tests/kins-switch applies G43.4 and a zero length in a tilted pose and after a point-to-point move: the joints hold, the point moves by the tilt term, and a move of nothing from the interpreter's point goes nowhere.

commit a515f33cb74920fb2e2d41e5be1393c76abe9cb9
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Sep 10 19:03:51 2026 +0800

    configs: the bridgemill sim shows off the tilted work plane family
    
    The old 5axisgui.ngc "drilled" a sphere with W words, W standing in for a tool length: the W axis of 5axiskins never drove a physical joint, the stroke folds into the XYZ slides, and the model's drawn quill hid that by cancelling the very motion that makes a W word work. The quill and its drawing lock go, so a W word shows the slides plunging, and 5axisgui.ngc keeps its name with comments saying what the controller cannot see. The sphere is then drilled two honest ways: g532-fused-orient-move.ngc, where G53.2 solves each plane and one fused G0 turns the head and travels to the hole, and g536-orient-then-move.ngc, where G53.6 reorients about the tip and a separate move travels in the plane. The demos and the M428 remap select the TCP kinematics with G12.1 P0, since on 5axiskins G13.1 lands on the identity. The AXIS GEOMETRY drops W: under TCP a W word never moves the tip, so W in the live plot only ever lied.

commit 98cc20c45113e34dda10b491be1d935b52a63750
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Sep 23 11:21:29 2026 +1000

    interpreter: keep the orientation poses inside the rotary travel
    
    The orientation codes took each pose the solver reported onto the turn nearest where the rotaries stood and ranked them by travel, without asking whether that turn was inside the joint's limits. A program that winds a rotary, a G68.4 incremental plane in a loop with G53.6, walked it past its limit, and motion refused the move in the middle of the program: "Linear move on line 9 would exceed joint 5's positive limit". The tilted work plane remap it replaces checked the limits and went the long way round.
    
    The interpreter reads [JOINT_n] MIN_LIMIT and MAX_LIMIT beside TYPE. Each angular joint of each pose goes onto the turn nearest where it stands that lies inside its travel, which is the long way round where the short way runs out, and a pose no turn brings inside is dropped before the ranking, so P0 takes the next nearest and P1 or P2 refuse. Under Q0 the table is freed before a pose is refused, as when nothing reaches the direction with it held. Where every pose that reaches the direction is outside the travel, the code refuses with that reason, at plan time rather than in motion.
    
    tests/twp-native stands C at 300 with a travel of 320, picks a plane whose nearest pose is the turn past the limit, and checks that G53.6 ends on the nearest pose inside the travel, with C inside it all the way.

commit a53033b49b9f5be539b81b65d880cf1bbf2a1f08
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Sep 17 23:16:09 2026 +1000

    interpreter: add G53.2, solve the tool orientation without moving
    
    G53.2 asks where the rotaries have to go for the tool to be normal to the active plane, like G53.1, and moves nothing: it publishes the pose on #<_orient_x> and kin and on #5071 to #5079, with #<_orient_valid> and #5080 saying a pose is held, so the program reaches it with a move of its own, for instance one G0 naming the linear and rotary words together, a single Cartesian move under TCP. Heidenhain's STAY. Reading the parameters before the first G53.2 is an error.
    
    Two fixes found on the way: a G68.3 block with axis words and a modal G0 emitted a stray move; and the solver's answers in (-180, 180] are unwrapped onto the turn nearest the present rotary position before the nearest-first ranking, or a rotary crossing 180 swings the long way round.

commit f131ae612e5b2aaaa67cae3e380a0097d99dab11
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Sep 9 21:09:03 2026 +1000

    motion: check a move against the joints the queue leaves behind
    
    The joint limit check inverted a move's endpoint from the joints the machine stands in. The reading runs far ahead, so every endpoint of a short program was checked from the starting pose, and an iterating inverse answers nearest whatever it is handed: park a robot at J4=-90, run a program that takes it to J4=90 and asks for a point, and the point is refused because it was inverted from the parked pose with the other wrist. Seed from the end of the queue instead: a joint segment knows its own end and the rest carry the answer the last endpoint came out with; with nothing queued the machine is the reference. The joint interpolated path already worked this way and shares the helper.

commit 771e4e30b84ccd1921f0c0a6b897718069ac20ae
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Sep 9 21:08:54 2026 +1000

    genserkins: hold the inverse to a step the Jacobian is good for
    
    The inverse took the whole Newton step the Jacobian asked for, and the Jacobian holds only near the estimate: an endpoint far from the seed asked for many radians, the arm landed somewhere unrelated and converged on a pose reached through whole turns. Seeded at 90 -90 0 0 90 -17.7 and asked for X450 Y-200 Z150 it answered joint 0 at -3263.962, the right pose nine turns out, which the joint limits refuse on a move the arm could make. Cap the step at GENSER_MAX_ANGLE_STEP and scale the whole vector so its direction survives, measured on the rotary links; a servo cycle asks for far less and is untouched.

commit e372753465f4619981fd88c3504a53854d44e894
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Sep 9 15:56:21 2026 +1000

    tests: the point-to-point moves and their preview on an iterative module
    
    pumakins answers the inverse in closed form and never looks at the joints
    it is handed, so tests/ptp-robot says nothing about the seed.  genserkins
    takes the Jacobian at those joints: the machine here homes well away from
    all zeros, so the seed has to come from where the machine stands, and all
    zeros is the singular pose it cannot come from at all.
    
    The same program goes through the interpreter and through the preview, and
    the two have to agree on where it ends up.  Then the arm is parked in the
    singular pose, where the module reports through the HAL library it prints
    with: the preview refuses, rather than the process going down.

commit cc2c5424fdf7e7d453d8015bf5469c514978ec67
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Sep 9 11:55:19 2026 +1000

    preview: let the canon report where the joints stand
    
    The preview has a machine to ask, through the status buffer it already
    reads for the tool table and the offsets, so it can answer for the joints
    as well.  Without them every inverse started from zeros, which previewed a
    point-to-point move from a pose the machine is not standing in, and on a
    serial arm could not be inverted at all.
    
    The one method on the mixin covers AXIS, gremlin and the Qt screens, which
    all take their canon from it.

commit 96cf9fcb05720db54c6d0fe641b0c8c1a04e98c5
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Sep 8 23:13:58 2026 +1000

    interpreter: seed the kinematics from the joints the machine stands in
    
    The interpreter works out the joints behind a point by inverting it, and
    had nothing to start the first inverse from but zeros.  A module that
    answers the inverse by iterating cannot be started anywhere: genserkins
    takes the Jacobian at the seed, and a serial arm with every joint at zero
    stands in a singular pose, so on a robot every G53.5 and G53.7 was refused
    with "the kinematics cannot invert the current position".
    
    Canon now reports the joint positions, and the interpreter falls back on
    them when its own seed no longer explains where the machine is.  They also
    name the arm the machine is standing in, which the inverse of a point
    cannot: a robot reaches the same point again with the elbow the other way
    up.

commit 3d97d24bd37544812be93244fe146e57980b3038
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Sep 8 20:23:32 2026 +1000

    interpreter, motion: hold the joints a point-to-point move asks for
    
    A point does not name one joint set: a robot wrist reaches it again with the forearm turned half a revolution, and both ends of a point-to-point move read the joints back from the point. The interpreter keeps its seed while it still explains where the machine is, instead of inverting the point every time and reporting joints the machine is not standing in, which had the next G53.7 refused on a joint limit. Motion holds the joints a joint segment ended on while the planner stays there, instead of inverting again the next cycle and undoing the move. tests/ptp-robot drives a wrist joint through zero and back and checks the joints not named stay put.

commit 67b77238f15c952e4ce6ff6dd77817ac4faefceb
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Sep 8 18:07:36 2026 +1000

    docs: say where the tilted work plane conventions come from
    
    The chapter and the G-code reference described the two angle forms but never said whose conventions they are: P0 is Heidenhain's PLANE EULER, P1 its PLANE SPATIAL, the numbering is Fanuc's, and Fanuc's fifth form is not implemented. Two differences from the control they borrow from are stated: P1 and P2 refuse where a control offering SEQ falls back to the nearer pose, and P names a pose only where a rotary turns the tool, so a machine whose rotaries all carry the work has only the nearest form; the G53.1 section read as though a tilting table had a pose to name.

commit 93483d526ccf5304270bc6c96c7b585e92c280b7
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Sep 8 16:04:42 2026 +1000

    tests: give the tilted work plane a plane that tells the forms apart
    
    Every plane in the frame test was one rotation of ninety degrees about a single axis, written four ways. With two angles zero, composing about the frame as it turns and about the fixed axes give the same matrix, so the difference between G68.2 P0 and P1, the whole reason they are separate codes, went unobserved. One plane at 25, 40 and -15 degrees instead, still written four ways, with the points and vectors derived from it; G68.4 and R take odd angles too, and G53 inside the plane lands somewhere that is not a permutation of the axes. Caught now: P0 composing the way P1 does, R composed before the plane rotation, the three-point form taking Y as X cross Z.

commit 30b147501bb636f9fb9afd8f22c4de3994633810
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sat Sep 5 00:58:37 2026 +1000

    configs: the nutating-head sims on the native tilted work plane
    
    The two trsrn_twp configs drop the python remap of G68.2, G68.3, G68.4, G69, G53.1, G53.3 and G53.6, its ngc wrappers, the abort handler that unwound it and the twp-status analog pin: the interpreter does all of it now, with nothing to restore on abort. The helper component that feeds the vismach model reads the plane from status. The demos select the TCP kinematics up front, since the orientation codes need it, and put kinematics 0 back at the end; square.ngc loses its G52, which a plane refuses.

commit b12115052095bde81c82952f3705101a4388d05f
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sat Sep 5 00:33:42 2026 +1000

    interpreter: the point-to-point moves and the tool orientation codes, G53.1 to G53.6, and G68.3
    
    The interpreter evaluates the kinematics module ahead of motion through the loader in kinematics_userspace, opened on first use on a HAL component of its own, so G53.n can ask the tool frame inverse where the rotaries go, G68.3 can read the tool direction, and the point-to-point codes can tell where their joints put the tool.
    
    G53.4, G53.5 and G53.7 are point-to-point moves, non-modal modifiers of G0 and G1 like G53: the path is interpolated in joint space, only the endpoint is defined. G53.4 takes a program point through the offsets. G53.5 reads the axis letters as a point in the machine frame with the orientation left out, XYZ the carriage in machine coordinates and the rotary letters the rotary joints, no offset applied: the world of the type the module flags KINSTYPE_MACHINE, the identity type where the slides line up with the frame, so there a letter names the joints the module's identity mapping gives it, and on a module with a slanted or composite slide the point goes through that module's own machine frame maths, a letter not given holding its machine coordinate. Where that type is a plain identity it is refused on a machine whose letters name joints of the other unit class, as a serial robot's X; a module that declares no types is read as letters = joints. G53.7 takes joint values as J<n>=<value> words, a form the lexer reads when the J value is followed by an equals sign, the joint's own position in its own units, which works on every machine. With G1 the move takes the time the straight move would at the programmed feed. The inverse ahead of motion is run to a fixed point, because a module may read the joints it is handed.
    
    G53.1 moves the rotaries to the plane's normal with the linear joints where they are; G53.6 does the same holding the tool centre point, a Cartesian move; G53.3 X Y Z goes to a point in the plane with the tool oriented. P picks among the poses: nearest by default, P1 and P2 by the sign of the secondary rotary, the one whose axis the other carries, found by turning each rotary through the module's tool frame, Heidenhain's SEQ+ and SEQ-. Q says whether the joints that carry the work take part: Q0 holds them, COORD ROT, falling back to everything free; Q1 frees them, TABLE ROT. G68.3 takes the plane from the tool, Z the tool axis as the joints have it, X the default tool X of the conventions chapter.
    
    tests/twp-native runs the xyzacb nutating head through all of it against the python maths in tests/kins-twp; tests/ptp-robot puts pumakins through the point-to-point codes; tests/ptp-machine-frame builds a module with a slanted Y slide out of tree and checks G53.5 holds machine X across a Y move, which the slides would not. Reversing the joint interpolation fails three checks in twp-native.

commit 856191c61fe13eda72199c4f727454cd75cd03a1
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sat Sep 5 00:22:08 2026 +1000

    motion: add the point-to-point move, interpolated in joint space
    
    A segment whose endpoint is Cartesian but whose interpolation is in joint space: the inverse runs once, at the endpoint, when the move is queued, and the planner runs every joint from where the queue ends to there together, the slowest setting the pace. Its length is the joint space distance with the tightest per-joint velocity, acceleration and jerk limits scaled onto it. Nothing blends into or out of it. While it runs the servo thread takes the joints from the planner and reports the tool from the forward kinematics; a forward that fails, as an iterating one can at the singularity the move is there to cross, leaves the last solved position and carte_pos_cmd_ok cleared. This is how a program crosses a singularity or flips a head without leaving its coordinate system.
    
    The move is a rapid with the rapid override or a feed that takes a given time with the feed override; the endpoint can also be given as joints, whose world position motion finds with the forward. Canon JOINT_TRAVERSE and JOINT_FEED, NML EMC_TRAJ_JOINT_MOVE and EMCMOT_SET_JOINT_LINE carry it; the preview draws the straight line between its ends. An external offset cannot ride on a joint segment: the queue refuses the segment while one is applied, and a request arriving while one is queued waits until the last joint segment is done. A queue reset forgets the joint-space bookkeeping with the queue.

commit 27b4ecb99808996321778f81db5a2f309ea1f59f
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Fri Sep 4 18:46:45 2026 +1000

    tests: put the nutating head kinematics next to the tilted work plane maths
    
    The two trsrn configs carry their orientation maths in python, written apart from the kinematics modules, and nothing had compared the two. tests/kins-twp loads each module in realtime with a small component answering frame and inverse requests over HAL pins and drives it from python holding the twp functions. Over a grid of primary, secondary and table angles the module's tool frame equals the python transformation matrix to 1e-9; for a set of requested tool axes with the table held as the remap holds it, the joint pairs the module finds are the python's candidates and the spin it reports is the python's virtual rotation. With nothing held the module may turn the table, which the python never does, so there each side is judged by the other's maths.

commit 03bbe0d3a6c184c702eef5a409bd44bdc1ee105a
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Oct 22 00:36:51 2026 +1100

    genserkins: report the tool frame
    
    genserkins reported no frames, so an arm described by its DH chain got none of the orientation codes, the tool marker or the tool jog frame, where pumakins, the same arm in closed form, had them all.
    
    The arm carries the tool and nothing turns the work, so the work frame is the identity. The tool frame is the flange frame the chain ends in, z along the last joint axis and out of the flange, declared with the same half turn to the convention as pumakins. The forward already reports that frame as roll, pitch and yaw in A B C, so the tool frame is that rotation, written out rather than taken through gomath or a posemath call the module does not link.
    
    scorbot-kins stays without: its controlled point is the wrist centre and A and B are the wrist joints passed through, so there is no tool frame to report. The kinematics conventions chapter says so.
    
    tests/kins-frames takes genserkins as it takes pumakins, and both gain a check that the tool frame turned back by the half turn is the rotation the forward's A B C describe; with the defaults, which are the PUMA of pumakins, the two modules give the same tool frame at the same joints. tests/kins-params expects genserkins to report a frame.

commit 0ba976dfff0a5a58394fc98bc99401fee6d1a1f8
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Oct 21 19:40:57 2026 +1100

    maxkins, xyzab_tdr_kins: report the tool and work frames
    
    Neither module reported its frames, so everything that needs them refused or did without on these two machines: the tilted work plane's orienting codes, the preview's tool marker, the tool jog frame and the turn of an offset across the tool.
    
    maxkins tilts the head about y by B and turns the table about z by C. The table turns the work by +C into the pose, so the work frame is Rz(-C); the head's tool frame is Ry(con*B), con the sign the conventional-directions pin selects, since the pin flips the tilt in the forward and the frame has to follow it: the W joint runs the tip out along (-con*sin(B), 0, -cos(B)), the tool axis reversed. xyzab_tdr_kins carries the work on both rotaries, so its tool frame is the identity and its work frame the transpose of the forward's coefficients of the X, Y and Z joints, as the trt modules do it.
    
    tests/kins-frames takes xyzab_tdr_kins and maxkins with the pin either way, and its quill check reads the tool axis from the work, which on a head over a turning table is where the forward reports the W joint's run; on 5axiskins the work frame is the identity and the check is unchanged. tests/kins-params expects their orientation joints. The kinematics conventions chapter says which in-tree modules still report no frames: genserkins, scorbot-kins, genhexkins and pentakins.

commit 4dcda01c7d35f371865cb108d5f8509af54a53fe
Merge: 1153e139 1c742124
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 08:22:31 2026 +0800

    Merge pull request #4775 from BsAtHome/hal64_kinematics
    
    kinematics: Use 64-bit HAL interface and adhere to new naming scheme

commit 1153e1395c648266cafded2a81f8a85754def524
Merge: f38a2013 6ad26ebc
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 9 08:22:01 2026 +0800

    Merge pull request #4771 from BsAtHome/hal64_update-sim_encoder
    
    hal: Update sim_encoder to 64-bit clean operation

commit f38a201317ae816603728c4eb71038d95477f266
Merge: 3a481bff dcb85464
Author: Rene Hopf <renehopf@mac.com>
Date:   Sun Nov 8 21:27:55 2026 +0100

    Merge pull request #4776 from rene-dev/gmoccapy-performance
    
    stop Gmoccapy from updating the labels all the time

commit 84a208c63a9d3741ef69df735a3d81dded12258e
Author: 85vmh <vasimihalca@gmail.com>
Date:   Sun Nov 8 17:41:56 2026 +0200

    tests: spindle-sync-scurve waits for the program to start, fails on overruns
    
    test-ui.py slept a fixed 0.5 s after AUTO_RUN and then waited for the
    interpreter to go idle. On a busy machine the program may not have
    started by then, the wait ended at once and the test failed with no
    samples. It now waits for the interpreter to leave idle first, within
    the same timeout.
    
    A sampler overrun drops samples, and the jump in Z across the gap
    would read as velocity ripple or jerk. The test now fails on any
    overrun before it checks the motion.
    
    The fix in the previous commit was tested on a Weiler E30 lathe: with
    the jerk-limited planner there is no oscillation while threading
    after the fix.
    
    Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

commit 99f22443e8d765c7deb790f3513a3a57111275a6
Author: Bertho Stultiens <bertho@vagrearg.org>
Date:   Sun Nov 8 14:32:05 2026 +0100

    hal: Update ilowpass and tests to use 64-bit clean operation
    tests: Update ilowpass/low-gain not to depend on wall time
    tests: Remove ilowpass/wrap-around because it depends on undefined behaviour

commit 3a481bff08c11ab5895cc32ce5209ca8cb062e8e
Merge: 7aee95df cd018129
Author: BsAtHome <bertho@vagrearg.org>
Date:   Sun Nov 8 13:12:25 2026 +0100

    Merge pull request #4762 from smoe/codex/xdr-upstream-readable
    
    xdr upstream readable

commit 7aee95dfcb5c3fc7ae59f1c89b84b0ac42e78161
Merge: f558b29c 6898815c
Author: BsAtHome <bertho@vagrearg.org>
Date:   Sun Nov 8 12:56:55 2026 +0100

    Merge pull request #4795 from grandixximo/tests-estop-reset-wait
    
    tests: wait for the E-stop reset before turning the machine on

commit f558b29c095a96beabac89063baedc0885915aa3
Author: Rene Hopf <renehopf@mac.com>
Date:   Sun Nov 8 11:28:40 2026 +0100

    Canon cleanup (#4748)
    
    * canon: move the NURBS math helpers to nurbs_math.hh
    
    The nurbs_* functions evaluate G5.2/G6.2 curves. They are plain math
    used by the canon implementations, not canonical commands, so they do
    not belong in the interface the interpreter calls.
    
    Drop the three declarations that were listed twice, and alpha_finder,
    which was declared but never defined.
    
    * canon: return whole poses from the position and tool offset queries
    
    GET_EXTERNAL_POSITION_*, GET_EXTERNAL_PROBE_POSITION_* and
    GET_EXTERNAL_TOOL_LENGTH_*OFFSET were nine functions each, one per axis.
    The interpreter always reads all nine together, and emccanon already
    built the whole pose for every single-axis call. Replace the 27
    functions with
    
        CANON_POSITION GET_EXTERNAL_POSITION();
        CANON_POSITION GET_EXTERNAL_PROBE_POSITION();
        EmcPose        GET_EXTERNAL_TOOL_LENGTH_OFFSET();
    
    so the interpreter makes one call where it made nine.
    
    The emccanon Python module keeps the per-axis names as wrappers, so
    remaps that call them, like stdglue.py, keep working.
    
    * canon: pass text as std::string_view, return the parameter file name
    
    MESSAGE, LOG, LOGOPEN and LOGAPPEND took a non-const char*, so callers
    holding a const string needed a cast. COMMENT and SET_PARAMETER_FILE_NAME
    took const char*. All six now take std::string_view, and the code behind
    them works on the view instead of copying it into a char buffer:
    
    - emccanon parses its hot comments (RPY, PROBEOPEN, PROBECLOSE) with
      string_view and writes the log and probe files through std::ofstream.
      setString/addString, used only there, are gone.
    - the preview renderer's comment hook takes the view, and the Python
      forwards pass it on as is.
    
    GET_EXTERNAL_PARAMETER_FILE_NAME filled a caller's buffer and returned
    an empty name when the name did not fit. It now returns a std::string,
    so PARAMETER_FILE_NAME_LENGTH is gone and the name has no length limit:
    the INI reader no longer rejects a long [RS274NGC]PARAMETER_FILE, and
    sai keeps the name in a std::string. From Python it was not callable at
    all (it wanted a char buffer) and now returns the name.
    
    CANON_ERROR was printf-variadic, but no caller passes arguments; it now
    takes the message as std::string_view. Callers that need formatting can
    use fmt::format. std::format is not an option while bookworm's GCC 12 is
    supported.
    
    The emccanon Python module gets small wrappers, since Boost.Python
    cannot convert to std::string_view.
    
    * sai: print canon calls with {fmt}
    
    PRINT and ECHO_WITH_ARGS wrapped fprintf, so a std::string_view had to
    be passed as "%.*s" with a separate length and pointer. They now use
    fmt::print, which takes a string_view as one argument and checks every
    format string at compile time. The UNEXPECTED diagnostics move to
    fmt::print as well.
    
    The output is unchanged: rs274 -g prints the same bytes as before for
    all 651 .ngc files under tests/ and nc_files/. START_SPEED_FEED_SYNC
    prints its bool with {:d}, because {} would print "true" where %d
    printed "1".
    
    rs274 already links -lfmt.
    
    * interp: remove the unused setup.log_file
    
    The interpreter logs through Interp::log_file, a FILE*. The char array
    of the same name in the setup struct was never read or written.
    
    * interp: keep program_prefix and wizard_root in std::string
    
    Both were PATH_MAX char arrays filled by realpath() into the buffer.
    They are now std::string, filled through a small real_path() helper
    that lets realpath() allocate the result.
    
    When realpath() fails the name is now empty. Before, glibc could leave
    the part of the path it had resolved in the buffer, and the
    subroutine search then looked in a directory that does not exist.
    
    findFile() only reads its directory and target, so they are const now.
    
    * interp: keep the error text in the Interp, as a std::string
    
    The text of the last error lived in a file-scope static char buffer, so
    every Interp in a process shared it. It is now the member saved_error_,
    which also drops the LINELEN limit on its length.
    
    getSavedError() returns a const std::string&, and setSavedError() takes
    a std::string_view. The two callers that copied the text into a fixed
    buffer before CHKS overwrote it now copy it into a std::string; one of
    them used an unbounded strcpy.
    
    * interp: return std::string from the InterpBase text getters
    
    error_text, line_text, file_name, stack_name, command and file each
    filled a caller's buffer and returned it. They now return a
    std::string. The buffers that existed only for these calls are gone:
    two globals in emctask.cc, the static savedError in gcodemodule.cc and
    the ones in sai. canterp keeps its file name in a std::string.
    
    file_name() returned an empty name when the name did not fit the
    buffer. It now returns the whole name, so for a name longer than the
    NML status field emctask now reports it truncated instead of empty.
    
    This changes the InterpBase interface, so an interpreter loaded with
    [TASK]INTERPRETER has to be rebuilt against the new header.
    
    rs274 -g prints the same output as before for all 651 .ngc files under
    tests/ and nc_files/, four of which end in an interpreter error.
    
    * interp: build file search paths in std::string instead of PATH_MAX buffers
    
    find_ngc_file() and findFile() now build their candidate paths with
    std::string and hand the result back as a std::string, so there is no
    length limit and no bare strcpy into the caller's buffer.  The repeated
    wordexp() calls go through a small expand_path() helper that frees each
    result; before, only the last one was freed.  A wordexp() failure now
    falls back to the unexpanded path instead of reading an uninitialised
    result, and an empty PROGRAM_PREFIX is skipped rather than searched as
    "(null)/name.ngc".
    
    SUBROUTINE_PATH is split with string_view and resolved with real_path(),
    so a long value is no longer silently truncated.  Empty entries are still
    skipped, and the "too many entries" message now only fires when there
    really is an extra entry.
    
    control_back_to() printed an uninitialised buffer as the file name when
    a subroutine file was not found; it now prints the <name>.ngc it looked
    for.
    
    save_parameters() reads the old .var file with std::getline and writes
    lines with fprintf, instead of going through a PATH_MAX-sized line
    buffer.  A missing file still reads as empty, without the /dev/null
    fallback.
    
    interp_from_shlib() builds the plugin path as a std::string.
    
    * interp: drop fixed buffers from the error stack, REMAP parsing and comment expansion
    
    The error call stack (_setup.stack) only ever holds __PRETTY_FUNCTION__
    or "Python", which are string literals, so it now keeps the pointers
    instead of copying each name into a 256-byte row.  The ERM/ERS/ERN
    macros share an ERROR_STACK_START() helper.  stack_name() and the Python
    error stack stop at the nullptr entry, and the Python side checks the
    array bound, since stack_index is writable from Python.
    
    parse_remap() splits the REMAP line into std::strings instead of copying
    it into a LINELEN buffer and running strtok_r on it, so a long line is no
    longer cut short.  The limit of 19 options is gone; extra options used to
    be dropped silently.  An empty REMAP line now reports an error instead of
    passing NULL to strstore(), which threw.
    
    convert_param_comment() appends to a std::string.  It used to write into
    a 513-byte buffer without checking the length, so a (DEBUG,...) comment
    with many parameters could overflow the stack; 120 copies of #1 expand to
    about 1600 characters.  Values longer than VAL_LEN still print as ######.
    
    write_state_tag() copies the file name into the fixed-size state_tag_t
    field with string_view::copy, as that struct is part of a motion message.
    
    * interp: build the remap call line in a std::string
    
    convert_remapped_code() built "O <name> call [v1][v2]..." in a
    char cmd[LINELEN], and add_parameters() strcat'ed each positional
    argument onto it without a length check. A remap with an '@' argspec
    and large word values, e.g. M400 P[10**300] Q[10**300], overflowed the
    stack buffer and crashed.
    
    The line is now built in a std::string. A line that is too long is
    rejected by read() with "Command too long" instead.
    
    * interp, task: review cleanups
    
    - nurbs_math.hh: drop the redundant extern on the prototypes.
    - restore_parameters() and save_parameters() take the file name as a
      const std::string &, so the callers no longer need .c_str().
    - print_interp_error(): indent the whole function with spaces.
    
    * interp: free the wordexp() result after WRDE_NOSPACE
    
    POSIX says a WRDE_NOSPACE failure may leave a partial result that
    still has to be freed. After any other error the result is untouched,
    so it is zero-initialised and only freed in those two cases.
    
    * interp: make stack_index read-only from Python
    
    The interpreter.stack_index property had a setter, so a remap could set
    it to a negative value and the next ERP would write before the start of
    the error stack. Nothing in the tree writes it, the example configs only
    read it, so the setter is removed. ERP also checks the lower bound now.
    
    * canterp, sai: stop the error stack loop
    
    SAI's report_error() prints stack names until it gets an empty one, but
    Canterp::stack_name() returned "<stack N>" for every index, so rs274
    with canterp and -s never stopped printing. Canterp has no call stack and
    now returns an empty name, and SAI stops after STACK_LEN entries in any
    case.
    
    * interp: close the parameter files on every error path
    
    save_parameters() returned on an out-of-range parameter number without
    closing the .new file, and left the half-written file behind on both of
    its error paths. It now holds the file in a unique_ptr and removes the
    temporary file on an error, so the old .var file stays as it is. It keeps
    stdio for the fdatasync().
    
    restore_parameters() had the same leak on an out-of-range number. It now
    reads with std::ifstream, like save_parameters() already does.
    
    * task: print the current orientation for an RPY comment without values
    
    When (RPY ...) did not have three numbers, the branch meant to print the
    current orientation printed the PM_RPY it had just failed to read into,
    which is uninitialised. It now prints the stored orientation converted
    to roll, pitch and yaw.
    
    * interp: reject REMAP lines that would have no effect
    
    parse_remap() accepted a number of REMAP lines that could never work:
    
    - a code outside the remappable range, like M1000 or G1, was stored but
      never looked up
    - M06 was stored under that name, but the built-in M6 looks for "M6"
      when it checks for recursion, so the remap called itself again
    - trailing characters after the number (M6x, G88.12) were ignored
    - an unknown option only printed a message
    
    All of these now fail at startup with the INI line. M-code remaps are
    stored as M<number>, so M06 and M6 are the same remap and a second one
    is reported as a duplicate. A failed REMAP line also sets the error text,
    so init no longer reports "Unknown error, bad error code". The
    unrecognized-option message printed the whole rest of the line, because
    it used a field width instead of a precision.
    
    tests/remap/introspect had REMAP=M123, which fell in the user M-code
    range and never did anything. It is now M423.
    
    * interp: always free the wordexp() result
    
    exp_result is zero-initialised, and after an error wordexp() either
    leaves a partial result (WRDE_NOSPACE) or restores what was passed in,
    so wordfree() is safe whatever it returned. Calling it unconditionally
    does not depend on which errors leave something behind.

commit ba4a7befa9b8d9b780fd53f66ed72abb90f0076e
Merge: 0777645f cb1d2a53
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 8 18:15:40 2026 +0800

    Merge pull request #4618 from grandixximo/axis-preview-m61
    
    preview: one preamble for every GUI, restating modes only

commit 0777645f08ae722a0fffa5317e8854d1b37ac0eb
Merge: b050c1f7 270e9a9e
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 8 18:09:36 2026 +0800

    Merge pull request #4601 from grandixximo/ini-strict-identifiers
    
    xhc-hb04: rename dashed ini identifiers, migrate old configs in update_ini

commit b050c1f720a9297f207d11021eaf6049ee9a5e8c
Merge: 40c6f75f 7c7e46ef
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 8 18:08:45 2026 +0800

    Merge pull request #4577 from grandixximo/homing-sync-group
    
    homing: run every leg of a synchronized home sequence together

commit 40c6f75f1afd26c912a7fa69a48e33470628768d
Merge: e96728fa 0ed1bbd5
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 8 18:02:57 2026 +0800

    Merge pull request #4675 from grandixximo/g432-no-motion
    
    interp: G43.1 and G43.2 axis words are offsets, never a move

commit e96728fabe524667199b36c623df73836b431098
Merge: c3d802a4 ef86cbad
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 8 17:56:34 2026 +0800

    Merge pull request #4677 from grandixximo/cycle-time-4424
    
    GUIs: read [DISPLAY]CYCLE_TIME with one rule

commit 44685c2d848b2f61545822c1631a2f57993102ac
Author: 85vmh <vasimihalca@gmail.com>
Date:   Sun Nov 8 00:42:46 2026 +0000

    tp: run position-synchronized moves trapezoidal with the S-curve planner
    
    The problem
    
    With [TRAJ]PLANNER_TYPE = 1, the jerk-limited S-curve planner, threading
    is unusable. A move synchronized to the spindle position (G33, G33.1 and
    the passes of G76) does not follow a planned profile: every servo cycle,
    tpSyncPositionMode() compares the axis with the spindle and asks for the
    velocity that closes the error, sized for an acceleration that can change
    at once. The S-curve planner limits jerk, so the acceleration it delivers
    lags the one asked for; the next correction is sized against an axis that
    is not where it was expected, and the axis oscillates around the spindle
    instead of locking to it. When the loop asks for zero velocity, Ruckig
    also rejects the limits and floods the log with
    "invalid limits (v=0.000000, ...)".
    
    On a simulated lathe (tests/motion/spindle-sync-scurve) a G33 K1.5 shows
    a Z velocity ripple of about 25 mm/s, Z wanders 0.5 mm against where the
    spindle says it should be, and over 1200 such messages are logged. On a
    machine that is a bad thread, and an axis pumping at the spindle speed.
    
    The fix
    
    tpUpdateCycle() runs a segment with tc->synchronized == TC_SYNC_POSITION
    as the trapezoidal planner does, through the same path the S-curve
    planner already takes when its own calculation fails: planner_type is
    taken as 0 for that segment and *mode is set to TP_SCURVE_ACCEL_ERROR,
    so the blend velocity of that cycle is the trapezoidal one too. mode is
    local to each cycle, so nothing carries over to the moves after.
    
    What it affects
    
    - Only PLANNER_TYPE = 1. With the default PLANNER_TYPE = 0 the planner
      was already trapezoidal and nothing changes.
    - Only position-synchronized segments: G33, G33.1 (rigid tapping) and
      the moves of G76. These are no longer jerk limited, which is what the
      trapezoidal planner has always done for them, and the axis follows the
      spindle again.
    
    What it does not affect
    
    - Feed per revolution (G95, TC_SYNC_VELOCITY), which follows a planned
      velocity and stays jerk limited.
    - Every unsynchronized move (G0, G1, arcs, probing) and jogging, which
      stay jerk limited.
    
    Test: tests/motion/spindle-sync-scurve runs a G1, a G33 and a G33.1
    with PLANNER_TYPE = 1 and samples Z against the spindle at the servo
    rate. It checks that no Ruckig error is logged, that the Z velocity
    ripple while tracking a steady spindle stays under 1 mm/s, that Z
    tracks the spindle within 0.01 mm, and that the G1 is still jerk
    limited. Without the fix the first three fail.

commit 6898815c8937f751a0205d063cd1833418972d14
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sat Nov 7 13:52:49 2026 +1100

    tests: wait for the E-stop reset before turning the machine on
    
    The abort in the E-stop reset queues the spindle override enable, which
    task issues on a later pass. These tests sent the machine on right
    after the reset, so on a loaded host the enable went out after ENABLE,
    or a later command replaced the queue before it went out, and the
    motion log no longer matched. Wait for the reset to complete, which
    task only reports once its queue is empty.

commit c3d802a4e71e6796748502a4704a6c69e3e8f7ab
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Fri Nov 6 23:15:35 2026 +0800

    hal: Add halcompupdate to migrate .comp files to the new HAL API (#4256)
    
    * hal: Add halcompupdate to migrate .comp files to the new HAL API
    
    Out-of-tree .comp components using the legacy HAL types (float, bit,
    s32, u32, s64, u64, signed, unsigned) and direct pin/param assignment
    stop working when the HAL API break is performed (#4099, #4247).
    halcompupdate rewrites them to the new API automatically:
    
    * declaration types are converted: float->real, bit->bool, s32->si32,
      u32->ui32, s64->sint, u64->uint, signed->si32, unsigned->ui32
      ('port' is left alone, it has no new-style replacement yet)
    * writes to out/io pins and to params become <name>_set(...) calls,
      including compound assignments, ++/--, array pins, chained
      assignments, *<name>_ptr dereferences and writes inside #define
      macros (macro parameters shadow same-named pins)
    * legacy C types are modernized (double/real_t -> rtapi_real,
      hal_bit_t -> volatile rtapi_bool, ...)
    * reads are unchanged and pins are never renamed, so existing HAL
      configurations keep working
    
    Constructs that cannot be converted safely are left unchanged with a
    warning for manual conversion: taking the address of a pin/param,
    direct use of the legacy hal_pin_*_new/hal_param_*_new creation API,
    postfix ++/-- whose value is used, and array indices with side
    effects.
    
    In-place rewriting is atomic (temp file + rename) and keeps a .bak
    backup created with O_EXCL|O_NOFOLLOW.
    
    halcompile now warns once per deprecated type, pointing to
    halcompupdate(1), at the spot previously marked for this warning.
    Docs: migration section in comp.adoc, new halcompupdate(1) manpage,
    SEE ALSO in halcompile(1).  Regression test in
    tests/halcompile/update-api.
    
    Validated by converting all in-tree components from master: 119/124
    compile (the other 5 need in-tree headers and fail identically for
    the already-converted versions), and the output matches the hand
    conversions in #4247 functionally.
    
    * halcompupdate: Warn on pin/param writes in EXTRA_SETUP
    
    Writes to pins/params inside EXTRA_SETUP convert cleanly to setters,
    but the setter uses a reference that halcompile initializes only after
    extra_setup() has run, so the converted component crashes when loaded
    (seen with multiswitch: top_position_set() on a NULL ref in
    extra_setup, #4272).
    
    Track the current body section while rewriting and warn when a
    converted write lands in EXTRA_SETUP, distinguishing params (direct
    assignment worked before, this is a regression) from pins (direct
    writes were already invalid).  EXTRA_CLEANUP and FUNCTION writes stay
    silent; the conversion itself is unchanged.
    
    * halcompupdate: Point EXTRA_SETUP write warnings at POST_EXPORT
    
    POST_EXPORT() (halcompile option post_export yes) is now the supported
    place for pin/param initialization that must happen after creation, so
    advise it instead of the first FUNCTION pass.  Assert the advice in the
    test.
    
    * halcompupdate: Preserve volatile for legacy hal_*_t types, print summary
    
    Body code converts legacy hal_*_t types to the volatile-preserving form ('hal_bit_t x' -> 'volatile rtapi_bool x'), semantics-identical whether or not the qualifier is load-bearing; each such conversion is reported with its line number so the spots can be reviewed.  'variable' declarations cannot express volatile, so legacy hal_*_t types there are reported and left unchanged for manual conversion.
    
    Body warnings now report file line numbers instead of body-relative ones.
    
    Each file ends with a summary of mechanical changes applied and constructs left for manual review.
    
    * halcompupdate: note names that spell a legacy type
    
    A pin, param, component or function name containing a legacy type as
    a segment (out_s32, input_bit, conv_s32_float) is stale once the type
    is removed at the API break.  Note it and suggest the new-style
    spelling (out_si32, input_bool, conv_si32_real), leaving the rename to
    the author: names are part of the HAL configuration interface - the
    component name is the loadrt/loadusr argument and module name,
    functions are exported as comp.N.name - so they are never changed, and
    the note does not affect the --check exit status or the manual-review
    count.
    The word in a name may not mean the type (plasmac's float_switch is a
    hardware float switch, demux's sel-bit counts bits of a value); the
    note is then simply dismissed.
    
    Only full segments match, so 'floating' is not noted for 'float', and
    duplicated segments are mentioned once.  'signed' and 'unsigned' are
    not checked in names: no sensible word replaces them there.  The note
    points at the line of the declaration itself, and the per-file summary
    reports the note count even when nothing else needed conversion.
    
    Run over all in-tree components: 54 names are noted (the 34 conv_*,
    abs_*, scaled_s32_sums and tristate_* component names, and 20 pins in
    demux, histobins, histobinstream, multiswitch, plasmac, reset,
    mesa_7i65), each a legacy type word used as a name segment.
    
    * halcompupdate: point 32-bit pins at sint and uint
    
    HAL is 64-bit only now. The tool still converts s32 and u32 to si32 and
    ui32, which keep the component's 32-bit behaviour for now, but that is a
    stopgap: the component has to be made 64-bit clean, and that takes an
    analysis of its code, since a value that passes through 32-bit
    intermediate storage or a 32-bit calculation is silently truncated. Each
    such declaration is noted with its line and counted in the summary, the
    documentation says so as a requirement, and a name that spells a type is
    suggested with sint and uint, as the in-tree renames spell it.
    
    The documentation now describes HAL after the API break: plain
    assignment to a pin no longer compiles and the legacy declaration types
    are accepted with a warning.
    
    * halcompupdate: leave C types to the author
    
    Only pins and params are safe to convert blind. A hal_*_t was a volatile value, nearly always wrong as a variable, and propagating the volatile into a conversion only hides that, so the tool no longer writes one. Every use of a hal_*_t or real_t is reported at its line and stays, with the plain type it most likely wants; the component does not compile until the author has looked at it.
    
    double and rtapi_real are the same type, and rewriting a variable float to rtapi_real changes its precision, so the rest of the C type conversion goes too, with --no-c-types. comp.adoc gets a section on what the old types were and what replaces them, as Bertho suggested.
    
    * halcompupdate: the API break has happened
    
    Warnings and notes still said a type "will be removed at the HAL API break". #4565 is in, so say what is true now: some of these are gone, the rest are deprecated.

commit cb1d2a53dae9152608dc5b6870ef0522d3cf6823
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sat Oct 3 15:21:47 2026 +1000

    preview: one preamble for every GUI, restating modes only
    
    AXIS restated the last block's tool change from stat.mcodes[3], so a
    reload after an MDI M61 Q1 ran a bare M61 and failed. The gremlin GUIs
    restated a bare G43, which in the preview takes the loaded tool's table
    offset, so after G43 H<other>, G43.1 or G43.2 the preview started at the
    wrong height. Reported by Sigma1912.
    
    preview_helpers.preview_initcodes() is now the one preamble: it restates
    only the slots that hold a mode, and the tool length offset in force as
    G43.1 or G49. AXIS, gremlin and qt5_graphics call it.
    
    Cutter radius compensation is not restated: with G41 or G42 active at load, the blocks after it were refused and the preview failed at line 0. G96 is restated with its S word, which a bare G96 lacked, the error Norbert reported on 2.9 in #4781.

commit 168b15054969b2c784876a11e02deb8ff4f9c2a3
Merge: dc1e7244 1b02fbc3
Author: BsAtHome <bertho@vagrearg.org>
Date:   Fri Nov 6 12:02:04 2026 +0100

    Merge pull request #4499 from grandixximo/halfileupdate
    
    hal: Add halfileupdate to convert HAL configuration files

commit 1b02fbc3e45c9715da4b69ffceac5bc7509b47b6
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Fri Sep 4 11:40:12 2026 +1000

    hal: Add halfileupdate to convert HAL configuration files
    
    Removing the 32-bit HAL types renames components, pins and parameters
    whose name spells a type that is gone (conv_s32_float -> conv_sint_real,
    mux-gen.00.in-s32-00 -> mux-gen.00.in-sint-00), so a configuration using
    those names fails to start.  halfileupdate rewrites them.
    
    A name is rewritten only when it resolves to an instance of a component
    that a loadrt in the files being read created, which covers count= and
    names= instances and components whose HAL prefix is not the module name
    without guessing; a name that does not resolve is left alone and
    reported.  Given an INI file, the HAL files it names are converted in
    the order LinuxCNC runs them, which is what makes a configuration
    convertible: its loadrt and its pin uses are regularly in different
    files.  An old name whose loadrt was converted already, from a file that
    another INI file shares, is converted too.  Keys of a user interface's own and keys outside [HAL] count,
    an INI value continued with a backslash is one command, and in haltcl
    the Tcl form 'hal setp name value' is understood as well.  Signal names,
    aliases, comments and names built with a substitution are never
    rewritten, though the type word on a newsig line is converted, and a
    linkpp line is reported since halcmd no longer has the command.  By
    default a diff is printed and nothing is written;
    --in-place rewrites atomically and keeps a .bak.
    
    The renames are tables in the tool itself, following the 64-bit only
    work: the eleven conv_* converters, abs_s32, abs_s64, scaled_s32_sums,
    the mux_generic and demux_generic pins, demux sel-u32, the histobins and
    histobinstream inputs and the reset pins.  They are regenerated if that
    set changes.  No part of HAL knows the old names, and both the tool and
    its tables are a migration aid for one release transition, not a
    permanent part of HAL.  The test therefore checks that the old names are
    gone and that what replaces them is consistent everywhere, not how any
    one name is spelled.

commit 1c7421241220e78b0d9088bc69f04e1eda2c828b
Author: Bertho Stultiens <bertho@vagrearg.org>
Date:   Wed Nov 4 15:23:33 2026 +0100

    kinematics: Use 64-bit HAL interface and adhere to new naming scheme.

commit dc1e724427db178558411e06038a866acac4b058
Merge: bed56ada 2d7618e7
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Nov 5 14:16:57 2026 +0800

    Merge pull request #4765 from BsAtHome/fix_runtests-various
    
    runtests: fix -s option and various

commit bed56ada527670eecb535ac316c69f6b3c4a26e4
Merge: 44a7a0c1 cabeba09
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Nov 5 08:56:50 2026 +0800

    Merge pull request #4753 from grandixximo/trsrn-inverse-pose
    
    xyzacb_trsrn, xyzbca_trsrn: take the rotary angles of the TCP inverse from the pose

commit 44a7a0c14c502d572548d2639f75c57ba7b35425
Merge: 0f7a279a a684daec
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Nov 5 08:56:45 2026 +0800

    Merge pull request #4756 from grandixximo/genhex-gui-forward
    
    switchkins: set the gui pins from the type in force when it is the gui type

commit 0f7a279aed70fa2906b2d268dffa82315f071f66
Merge: 469f9dd5 ed8c2d37
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Nov 5 08:56:39 2026 +0800

    Merge pull request #4751 from grandixximo/tests-rt-probe-queue
    
    tests: pass when a realtime host reports a late servo period

commit 469f9dd5a4c90a457484d94c604a54d9f1254eed
Merge: 2ec90f62 132f14c9
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Nov 5 08:56:34 2026 +0800

    Merge pull request #4758 from grandixximo/kins-switch-unsolved-waits
    
    tests/kins-switch-unsolved: wait for what each step needs, not for a time

commit 2ec90f62f42da0cc98ce4abbec85c5b96424dd47
Merge: d970a6b4 8c069b71
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Thu Nov 5 08:56:29 2026 +0800

    Merge pull request #4763 from grandixximo/g92-applied-errors
    
    interp: G92.1, G92.2 and G92.3 report their errors

commit dcb85464ec4d601736690fb3b9ec361893209be5
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 4 23:48:31 2026 +0100

    gmoccapy: stop the warning dialog's pin timer when it closes
    
    warning_dialog() watches the confirm and active pins with a 100 ms
    timer that only ends when a pin closes the dialog. Closing it with
    the Ok button left the timer running forever, so every operator
    warning leaked a timer, which later tried to close a destroyed dialog
    when the pin went high.
    
    Remove the timer after the dialog returns, unless a pin already
    ended it.

commit 35f47266db0bcc31cdeb02fcc262324dec490c0a
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 4 23:48:31 2026 +0100

    gremlin: don't add a poll timer every time the preview is shown
    
    Gremlin.map() started a new 50 ms poll timer each time the widget was
    mapped, and poll() never stops, so every hide and show of the preview
    (eg opening and leaving gmoccapy's settings page) left one more timer
    polling linuxcnc status for the rest of the session.
    
    Keep the timer id, start it only if none is running, and stop it on
    unmap since there is nothing to draw while hidden.

commit 56060ff936c0240abdab48580759ac8552be1ed9
Author: Rene Hopf <renehopf@mac.com>
Date:   Wed Nov 4 23:48:14 2026 +0100

    gmoccapy: only set labels whose text changed
    
    GTK relayouts the whole window on every GtkLabel set_label()/set_text(),
    even when the text is the same. gmoccapy rewrote the feed, velocity,
    spindle and Vc labels and the clock every 100 ms cycle, and Combi_DRO
    its three readouts on every position update, so an idle gmoccapy
    redrew its window 10 times a second.
    
    Only set a label when its text changed, and update the clock from the
    1 s timer, since it only shows seconds.
    
    Idle 4-axis sim: CPU from ~10.5% to ~7% of one core, window redraws
    from 10/s to 1/s.

commit d970a6b43bb66c99f65a840016d0f8c6c99180f4
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Nov 4 20:52:02 2026 +0800

    Faster test runs: a 2 s wait at every shutdown, and two tests that waited out a timeout (#4770)
    
    * task: release iocontrol.0 when milltask exits
    
    Since the IO handling moved into task, milltask owns the iocontrol.0
    component but never called hal_exit() on it, so the component stayed
    registered after milltask was gone.  The Task destructor now releases
    it and the shutdown deletes the Task object.
    
    * linuxcnc: do not wait on the thread pseudo components at shutdown
    
    Cleanup waits for every component but halcmd to go before it stops
    realtime.  A thread is listed as a __<name> pseudo component, which
    unload all leaves in place, so together with the stale iocontrol.0 the
    wait always ran its full 2 seconds.  Each linuxcnc -r in the tests
    paid it, and mdi-while-queuebuster-waitflag starts linuxcnc 20 times.
    
    * tests: abort/g64 and workplane-retain abort without the 5 s wait
    
    Both called wait_complete() right after AUTO_RUN.  For a program run
    that waits for the end of the program, which these never reach before
    the abort, so every case sat out the 5 second timeout.  Wait for the
    point to abort at instead: the Y position in abort/g64, which then also
    waits for halsampler to log it, and in workplane-retain the slow move
    with the read ahead stopped at the queue buster or M2, in place of the
    fixed sleeps.  The other command waits get 30 seconds, so a loaded
    machine is not cut off at the 5 second default.
    
    * tests: split abort/g64 into its five cases
    
    The test ran five mode settings back to back in one linuxcnc session,
    about 45 seconds, which made it the floor of a parallel run.  Each
    setting with its redo is now a test of its own in a directory named
    after it; the one-line test.ini includes the shared settings, now in
    g64.inc, and test-ui.py picks the case by the directory.  The checks
    are the same.
    
    Measured by hdiethelm in #4770: with this and the slow tests started
    first, -j 32 goes from 48 to 32 seconds.

commit 6ad26ebcbf66cc2b54a15343832f7ea070139b1c
Author: Bertho Stultiens <bertho@vagrearg.org>
Date:   Tue Nov 3 15:24:08 2026 +0100

    hal: Update sim_encoder to 64-bit operation.

commit 2d7618e7d698dc3d3a9fa978788b85758c4db3c4
Author: Bertho Stultiens <bertho@vagrearg.org>
Date:   Mon Nov 2 16:40:16 2026 +0100

    runtests: Update parallel run to be able to stop with -s on a failed test
    runtests: Fix various typos and comment style problems
    runtests: Test availability of parallel and bwrap
    runtests: Fix and update usage message
    runtests: Fix results collection race

commit 0fc9f358a104f091c033716c8e745d1c52440288
Merge: ad8dd1b0 c2b4fad6
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Nov 4 12:51:43 2026 +0800

    Merge pull request #4773 from BsAtHome/hal64_update-pid
    
    hal: Update the pid component to 64-bit clean operation

commit ad8dd1b02d9be48bb646b969dff0fc8e1d00d811
Merge: f2944ca5 f34a4563
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Nov 4 12:42:16 2026 +0800

    Merge pull request #4772 from BsAtHome/hal64_debounce-modmath
    
    hal: Update debounce and modmath to run 64-bit clean

commit f2944ca556211da0baf270251c50bcd4b6d082db
Merge: cdf957bd 4e291c27
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Wed Nov 4 12:38:49 2026 +0800

    Merge pull request #4768 from hdiethelm/tooldata_mmap_error_messages
    
    tooldata_mmap: Improve error messages

commit 4e291c27fc817dad3f1cd6a45dbd4e83076dbb36
Author: Hannes Diethelm <hannes.diethelm@gmail.com>
Date:   Mon Nov 2 21:17:09 2026 +0100

    tooldata_mmap: Improve error messages

commit c2b4fad6dfd28d67c971cce5241cb4aeb6883f1d
Author: Bertho Stultiens <bertho@vagrearg.org>
Date:   Tue Nov 3 15:41:35 2026 +0100

    hal: Update the pid component to 64-bit clean operation.

commit f34a45630ed13961d346f45b8b47fb23b25810d8
Author: Bertho Stultiens <bertho@vagrearg.org>
Date:   Tue Nov 3 15:28:12 2026 +0100

    hal: Update debounce and modmath to run 64-bit clean.

commit cdf957bd00bbcc4c569f01e7eed5b154422b816c
Merge: 67437d88 9cd4f470
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Nov 3 10:22:10 2026 +0800

    Merge pull request #4769 from grandixximo/kins-params-no-sudo
    
    tests: kins-params builds its components without sudo

commit 9cd4f470a8adee6daca989fc474dbfed8cbf0eac
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Tue Nov 3 11:30:35 2026 +1100

    tests: kins-params builds its components without sudo
    
    The test installs with halcompile into the run-in-place tree, which the
    user can write, and its skip file already keeps it off installed
    packages, so the sudo was never needed.  tests/README: tests never use
    root or sudo.
    
    Fixes #4764

commit cd01812900701a815cd028ff70141ae8d78f8e46
Author: Steffen Moeller <moeller@debian.org>
Date:   Mon Nov 2 23:21:24 2026 +0100

    nml: make the XDR compatibility header self-contained
    
    Include config.h inside nml_xdr_compat.h and include that header first in
    cms_xup.cc, preserving configuration before system-header processing.
    Use a container-prefixed include guard and mark this new header LGPL
    version 2 or later.
    
    Clarify that declaration checks select compatibility replacements, while
    the signed 16/32/64-bit primitives remain required by the link check.
    Adapter behavior and the RPC/TI-RPC discovery fallback are unchanged.
    
    Validation: isolated native macOS configure; C11 and C++20 wire fixtures
    (176 assertions each), with no caller-side config.h and repeated header
    inclusion; configuration-before-RPC include traces; 32 synthetic provider
    selections and 24 missing-declaration/definition controls. No project
    targets built. Native Linux validation was not repeated.

commit f208d243b910a29454cefdf4bae7d8c882a3e7bd
Author: Steffen Moeller <moeller@debian.org>
Date:   Sun Nov 1 23:14:09 2026 +0100

    nml: adapt missing fixed-width XDR entry points
    
    Some system RPC/XDR implementations do not declare every fixed-width
    filter CMS_XDR_UPDATER uses. The tested macOS SDK omits xdr_int8_t,
    xdr_uint8_t and xdr_uint{16,32,64}_t, while providing the corresponding
    unsigned xdr_u_int{16,32,64}_t primitives.
    
    Check the five names with AC_CHECK_DECLS. For names not declared,
    libnml/cms/nml_xdr_compat.h maps unsigned 16/32/64-bit routines to their
    xdr_u_intN_t equivalents, with the same 4/8-byte encodings. The signed and
    unsigned 8-bit adapters send one 32-bit XDR word, matching glibc/libtirpc:
    decoding narrows without a range check, leaves the destination unchanged
    on failure, and XDR_FREE is a no-op.
    
    Declared native routines are always used. Where all five names are
    declared, the header only includes rpc/rpc.h and stdint.h. config.h gains
    five HAVE_DECL_* results, which cms_xup.cc includes before the header.
    The configure link test includes only system headers. It checks native
    routines when declared and the primitives needed by the selected fallbacks
    otherwise; the compatibility header is used only when compiling NML.
    
    Mark the new header LGPL Version 2, matching the neighboring CMS files.

commit 8c069b71e8969dd620ad34caa91a08ca21e1a99f
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 2 16:58:10 2026 +1100

    interp: G92.1, G92.2 and G92.3 report their errors
    
    convert_g() stored the result of convert_g92_is_applied() in status and went on without checking it, since G92.2 and G92.3 got their own modal group in 26aeab962d (2016). So every refusal of G92.1, G92.2 and G92.3 was dropped: the code stopped before changing anything and the line carried on as if it had run. Under cutter radius compensation a G92.1 did nothing instead of raising "Cannot change axis offsets with cutter radius comp", and under a tilted work plane none of the three raised "Cannot change G92 offsets while a tilted work plane (G68.2) is active" the way G92 does. The result is checked now, like every other step there.
    
    tests/interp/g68-words runs G92.1, G92.2 and G92.3 in a tilted work plane and G92.1 under G41.1; all four were "ok" before.

commit ed8c2d375b604fbc46289eb0e2c8e20c9ceeeaf3
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 2 14:32:16 2026 +1100

    tests: pass when a realtime host reports a late servo period
    
    On a realtime host rtapi_app reports a late servo period once per
    session, and motion passes the report on to the error channel. On the
    rtpreempt buildbot that happens in a dozen or more tests per run, at a
    random point. These tests failed on any extra message on the error
    channel, or expected a specific one next, so leave that report out:
    axis-type, jog-speed-change, kins-switch, kins-switchkins-core,
    m62-m68-range, tlo, tp/helix-motion and workplane-preview. linuxcncrsh
    gets it back from a 'get error' in place of OK, so checkresult turns it
    back into OK before the diff.

commit 132f14c914262f004c3e340cb90c3cba9af0f974
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Nov 2 14:32:16 2026 +1100

    tests/kins-switch-unsolved: leave out a late servo period report
    
    On a realtime host rtapi_app reports a late servo period once per
    session, and motion passes the report on to the error channel, where
    the test took it for an unexpected message after the switch.

commit d7226451c6857904679d95c0402e5a826aec9b15
Author: Steffen Moeller <moeller@debian.org>
Date:   Sun Nov 1 23:13:16 2026 +0100

    configure: check the system XDR routines NML uses
    
    NML's CMS_XDR_UPDATER (libnml/cms/cms_xup.cc) serializes through the
    system RPC/XDR implementation, but the later usability probe calls
    get_myaddress, which NML does not use.
    
    Probe the fixed-width integer filters, xdrmem_create and stream position
    and destroy macros that cms_xup.cc already uses. This is expected to be
    neutral on working Linux configurations and diagnoses missing declarations
    or symbols in config.log before building NML. The probe only compiles
    and links; char, bytes, vector, float and double filters are not covered.
    
    Calls use parenthesized names so an undeclared function is an error even
    where older C compilers would implicitly declare a plain call. Stream
    operation macros remain unparenthesized so they can expand.
    
    The earlier rpc/rpc.h and libtirpc discovery is unchanged, including its
    get_myaddress library-symbol check.

commit 67437d8865e431a9a33f74cee912dbf891d3b4c5
Merge: eedb9cc8 a724d61d
Author: BsAtHome <bertho@vagrearg.org>
Date:   Sun Nov 1 13:20:48 2026 +0100

    Merge pull request #4687 from tzuohann/fix-demux-bargraph-3519
    
    demux: bargraph turns on its highest output (#3519)

commit eedb9cc84edbec456d7bfdd9f33d40219d62fe2b
Author: Hans Unzner <hansunzner@gmail.com>
Date:   Sun Nov 1 12:15:04 2026 +0000

    Add flipflop timing diagram (#4750)
    
    * docs:  add timing diagram for flipflop component
    * flipflop: initialize out-not to 1

commit ecf565751f0fbf4303a627cc2f01b3d3a66edfa8
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 1 15:10:32 2026 +1100

    tests/kins-switch-unsolved: wait for what each step needs, not for a time
    
    Tests run in parallel and under load. The test homed right after the machine-on command without waiting for it, and gave the error channel and the status a fixed 0.2 s after each MDI command to catch up. It now waits for machine on, all joints homed and the mode it asks for; after each command for the interpreter idle with the machine in position; for the report of the failed switch itself; and, before reading the position or checking that nothing else was reported, for a status newer than the event: the motion heartbeat changed and two task cycles gone, since task passes motion's reports on to the error channel in its cycle.
    
    It has not been seen failing; six copies at once with four busy loops, twice, pass before and after.

commit a684daec04e222189c2bb9674ddc82aa8f1099c9
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 1 13:16:20 2026 +1100

    switchkins: set the gui pins from the type in force when it is the gui type
    
    When gui_kinstype is set (genhexkins sets it to its own type), kinematicsForward() ran the gui type's forward after the type in force on every call. With genhexkins in force that is the same iterative forward on the same joints a second time: it costs a Newton iteration and a pass over the parameter block each servo cycle, and it writes genhexkins.last-iterations again, so that pin always read 1 instead of the iterations the forward took. When the type in force is the gui type, its pose is now the gui pose; under the identity type the gui forward still runs, as the hexapod vismach display needs it.
    
    Along a moving path in the hexapod-sim geometry, a forward with genhexkins in force goes from 4.2 to 3.0 microseconds; the identity type is unchanged at 1.2, and the gui pins carry the same values. tests/genhexkins-forward now also requires last-iterations to read more than 1 after the checker's last forward, which fails without the change.

commit 06864e23559e70463fc7112d5ce77138bcbc288c
Merge: 654b0a41 74372b31
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Sun Nov 1 10:13:18 2026 +0800

    Merge pull request #4755 from BsAtHome/fix_runtests-parallel
    
    tests: Fix invocation of self using the proper RUNTESTS variable
Created: 2025-03-16 Last update: 2026-11-12 01:17
Depends on packages which need a new maintainer normal
The packages that linuxcnc depends on which need a new maintainer are:
  • dblatex (#942402)
    • Build-Depends-Indep: dblatex
  • docbook-xsl (#802370)
    • Build-Depends: docbook-xsl
Created: 2022-02-27 Last update: 2026-11-12 01:17
testing migrations
  • excuses:
    • Migrates after: boost1.90
    • Migration status for linuxcnc (- to 1:2.9.9-2): BLOCKED: Rejected/violates migration policy/introduces a regression
    • Issues preventing migration:
    • ∙ ∙ Updating linuxcnc would introduce bugs in testing: #1089809
    • ∙ ∙ New but not reproduced on amd64 - info: linuxcnc-doc-de, linuxcnc-doc-en, linuxcnc-doc-es, linuxcnc-doc-fr, linuxcnc-doc-zh-cn, linuxcnc-uspace
    • ∙ ∙ New but not reproduced on arm64 - info: linuxcnc-doc-de, linuxcnc-doc-en, linuxcnc-doc-es, linuxcnc-doc-fr, linuxcnc-doc-zh-cn, linuxcnc-uspace
    • ∙ ∙ New but not reproduced on armhf - info: linuxcnc-doc-de, linuxcnc-doc-en, linuxcnc-doc-es, linuxcnc-doc-fr, linuxcnc-doc-zh-cn, linuxcnc-uspace
    • ∙ ∙ New but not reproduced on i386 - info: linuxcnc-doc-de, linuxcnc-doc-en, linuxcnc-doc-es, linuxcnc-doc-fr, linuxcnc-doc-zh-cn, linuxcnc-uspace
    • ∙ ∙ Depends: linuxcnc boost1.90 (not considered)
    • Additional info (not blocking):
    • ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/l/linuxcnc.html
    • ∙ ∙ Autopkgtest for linuxcnc/1:2.9.9-2: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass
    • ∙ ∙ Required age reduced by 3 days because of autopkgtest
    • ∙ ∙ 136 days old (needed 2 days)
    • Not considered
news
[rss feed]
  • [2026-06-30] Accepted linuxcnc 2.9.0~pre1+git20230208.f1270d6ed7-1+deb12u2 (source) into oldstable-proposed-updates (Debian FTP Masters) (signed by: Petter Reinholdtsen)
  • [2026-06-30] Accepted linuxcnc 1:2.9.4-2+deb13u1 (source) into proposed-updates (Debian FTP Masters) (signed by: Petter Reinholdtsen)
  • [2026-06-28] Accepted linuxcnc 1:2.9.9-2 (source) into unstable (Petter Reinholdtsen)
  • [2026-06-27] Accepted linuxcnc 1:2.9.9-1 (source) into unstable (Petter Reinholdtsen)
  • [2026-01-25] linuxcnc REMOVED from testing (Debian testing watch)
  • [2025-11-11] linuxcnc 1:2.9.7-1 MIGRATED to testing (Debian testing watch)
  • [2025-11-03] Accepted linuxcnc 1:2.9.7-1 (source) into unstable (andypugh) (signed by: Steffen Moeller)
  • [2025-05-20] linuxcnc 1:2.9.4-2 MIGRATED to testing (Debian testing watch)
  • [2025-04-13] Accepted linuxcnc 1:2.9.4-2 (source) into unstable (Steffen Moeller)
  • [2025-03-15] Accepted linuxcnc 1:2.9.4-1 (source) into unstable (Steffen Moeller)
  • [2025-03-11] linuxcnc REMOVED from testing (Debian testing watch)
  • [2025-01-31] linuxcnc 2.9.3-2 MIGRATED to testing (Debian testing watch)
  • [2025-01-27] Accepted linuxcnc 2.9.0~pre1+git20230208.f1270d6ed7-1+deb12u1 (source) into proposed-updates (Debian FTP Masters) (signed by: Petter Reinholdtsen)
  • [2025-01-26] Accepted linuxcnc 2.9.3-2 (source) into unstable (Petter Reinholdtsen)
  • [2025-01-20] linuxcnc REMOVED from testing (Debian testing watch)
  • [2024-07-09] linuxcnc 2.9.3-1 MIGRATED to testing (Debian testing watch)
  • [2024-07-07] Accepted linuxcnc 2.9.3-1 (source) into unstable (Petter Reinholdtsen)
  • [2023-12-28] linuxcnc REMOVED from testing (Debian testing watch)
  • [2023-11-06] Accepted linuxcnc 2.9.1-2 (source) into unstable (Steffen Moeller)
  • [2023-10-26] Accepted linuxcnc 2.9.1-1 (source) into unstable (Andy Pugh) (signed by: Steffen Moeller)
  • [2023-02-13] linuxcnc 2.9.0~pre1+git20230208.f1270d6ed7-1 MIGRATED to testing (Debian testing watch)
  • [2023-02-10] Accepted linuxcnc 2.9.0~pre1+git20230208.f1270d6ed7-1 (source) into unstable (Sebastian Kuzminsky) (signed by: Petter Reinholdtsen)
  • [2022-11-11] linuxcnc 2.9.0~pre0+git20221105.ffb6bda926-1.2 MIGRATED to testing (Debian testing watch)
  • [2022-11-08] Accepted linuxcnc 2.9.0~pre0+git20221105.ffb6bda926-1.2 (source) into unstable (Petter Reinholdtsen)
  • [2022-11-08] Accepted linuxcnc 2.9.0~pre0+git20221105.ffb6bda926-1.1 (source) into unstable (Petter Reinholdtsen)
  • [2022-11-06] Accepted linuxcnc 2.9.0~pre0+git20221105.ffb6bda926-1 (source) into unstable (Sebastian Kuzminsky) (signed by: Petter Reinholdtsen)
  • [2022-09-12] linuxcnc 2.9.0~pre0+git20220906.02744cdef6-1 MIGRATED to testing (Debian testing watch)
  • [2022-07-15] linuxcnc 2.9.0~pre0+git20220402.2500863908-4 MIGRATED to testing (Debian testing watch)
  • [2022-07-14] linuxcnc REMOVED from testing (Debian testing watch)
  • [2022-07-14] linuxcnc REMOVED from testing (Debian testing watch)
  • 1
  • 2
bugs [bug history graph]
  • all: 9
  • RC: 1
  • I&N: 5
  • M&W: 3
  • F&P: 0
  • patch: 1
links
  • homepage
  • lintian (1, 55)
  • buildd: logs, cross
  • popcon
  • browse source code
  • other distros
  • security tracker
  • l10n (-, 9)
  • debci
ubuntu Ubuntu logo [Information about Ubuntu for Debian Developers]
  • version: 1:2.9.9-2ubuntu1
  • 2 bugs
  • patches for 1:2.9.9-2ubuntu1

Debian Package Tracker — Copyright 2013-2025 The Distro Tracker Developers
Report problems to the tracker.debian.org pseudo-package in the Debian BTS.
Documentation — Bugs — Git Repository — Contributing