emc-developers — Developer specific. For issues of interest to users see emc-users list (below)

Re: [Emc-developers] 2.10 Proposals

[Bertho S. <lc...@va...>]

On 10/29/25 12:34 AM, andy pugh wrote:
> There are three things that I would like to see in 2.10, only one of 
> which is likely to be uncontentious.[snip]
I think the HAL name length should be increased from the current 47 to 
something more substantial, like 127 or 255. I've run into and over the 
limit several times.

And, running over the limit can cause some interesting crashes where you 
would not expect it (and hard to debug). Sure, the length checks should 
have been there everywhere, but they are not. The error tests and 
controls are apparently too lax.

That also invites the thought that many components need to be updated to 
perform proper and consistent error checking, through and through. 
Possible errors at module load/init time are not always handled or 
handled properly.


While we're at it, the shared mem size could also be upped (maybe to 48M 
or 64M) as there are no longer real issues with physical memory pressure 
anyway. The data sets have also become larger with the transition to 
64-bit systems.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] 2.10 Proposals

[Jon E. <el...@pi...>]

On 10/29/25 12:33, andy pugh wrote:
> On Wed, 29 Oct 2025 at 17:00, Jon Elson <el...@pi...> wrote:
>
>> Yes, this is what I'm concerned about.  How does a negative
>> signed 32-bit value get converted to 64-bit?  There are
>> 32-bit encoder counts
> There won't be when I have finished.
> At least not inside LinuxCNC drivers.
> There may be 32-bit input sources, but I am not aware of any. ppmc
> appears to sign-extend 24 bits to 32. That will be expanded to 64.
> There are 16-bit input sources (Modbus and Smart-serial for example)
> but those are already sign-extended (and in many cases are _already_
> internally 64-bit)

Specifically in my ppmc encoder driver section, I remember 
some fancy footwork looking at the sign of the 24-bit values 
and the sign and next bit of the 32-bit extension, to decide 
when a rollover is required.  This took some hard thinking 
and testing to get right.

Jon

[Emc-developers] Trajectory planner velocity, non trivial kinematics?

[Nicklas SB K. <nk...@nk...>]

Have looked on the general serial kinematics module and it seems the jacobian  is calculated but never used. Also
started to read thru the code for the trajoctory planner. Got the impression the trajectory planner does not handle
velocity constraints for joints velocities or accelerations properly?

If this is the case. Anyone know if someone started a branch for this? Any other documents like for example scientific
articles or similar on the topic?



Regards Nicklas Karlsson

Re: [Emc-developers] 2.10 Proposals

[rodw <ro...@ve...>]

Ref:   https://linuxcnc.org/docs/stable/html/config/ini-config.html#sub:ini:sec:traj

TPMOD =   alternate_trajectory_planning module   [tp_parms=value]

The   TPMOD   variable is optional. If specified, use a specified (user-built) module instead of the default (tpmod). Module parameters (tp_parms) may be included if supported by the named module. The setting may be overridden from the command line using the -t option ($ linuxcnc -h).

Its very easy to modify the build system to include an extra folder.
Rod
 
On 2025-10-29 22:11, andy pugh  <bod...@gm...>  wrote:
> On Wed, 29 Oct 2025 at 07:57, rodw  <ro...@ve...>  wrote:
> >
> >  Given the TP is supposed to be a stand alone module, why don't you deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and allow users to experiment with it on real hardware by changing their ini file settings?
>
> Are you sure this is the case? Which INI file setting?

Re: [Emc-developers] 2.10 Proposals

[andy p. <bod...@gm...>]

On Wed, 29 Oct 2025 at 17:00, Jon Elson <el...@pi...> wrote:

> Yes, this is what I'm concerned about.  How does a negative
> signed 32-bit value get converted to 64-bit?  There are
> 32-bit encoder counts

There won't be when I have finished.
At least not inside LinuxCNC drivers.
There may be 32-bit input sources, but I am not aware of any. ppmc
appears to sign-extend 24 bits to 32. That will be expanded to 64.
There are 16-bit input sources (Modbus and Smart-serial for example)
but those are already sign-extended (and in many cases are _already_
internally 64-bit)
 (in fact in smart-serial there can be 8-bit encoder counter values
extended to 64)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] 2.10 Proposals

[Peter W. <pc...@me...>]

On Wed, 29 Oct 2025, Robert Schöftner wrote:

> Date: Wed, 29 Oct 2025 17:46:45 +0100
> From: "Robert [ISO-8859-1] Schöftner" <rm...@un...>
> Reply-To: EMC developers <emc...@li...>
> To: emc...@li...
> Subject: Re: [Emc-developers] 2.10 Proposals
> 
> Am Mittwoch, dem 29.10.2025 um 09:17 -0700 schrieb Peter Wallace:
>>
>> Yes, many components/drivers have parameters rather than pins for
>> this reason.
>>
>> In many cases, parameters are not expected to change at run time and
>> if
>> changed may cause issues.
>>
>>
>
> Even now you can change parameters at runtime ("setp" in halcmd)
>
> It's not like the concept of a parameter will be removed. It is a HAL-
> internal change that will allow the code to get rid of a bunch of
> pin/parameter checks und duplicated slightly different code.
>
> rene_dev could probably tell a bit more...
>


As long as its just internal changes, but changing the external hal pin type 
removes a way of indicating statics which are used in many components and 
drivers.

>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Peter Wallace
Mesa Electronics

Re: [Emc-developers] 2.10 Proposals

[andy p. <bod...@gm...>]

On Wed, 29 Oct 2025 at 16:03, Bertho Stultiens <lc...@va...> wrote:
>
> On 10/29/25 12:34 AM, andy pugh wrote:
> > 1) Convert all int HAL pins to 64-bit.
>
> This will need *a lot* of work because code written for 32-bit uses
> tricks and whatnot that are not necessarily compatible with 64-bit.
> ...Each instance must be
> found and properly re-coded for 64-bit.

Indeed, and this is why it is taking so long.
However, in most cases any internal 32-bit value can remain 32-bits,
and will just get written to a 64-bit HAL pin.

The reason to push for this is _precisely_ because we have instances
of values being truncated (think high count and high speed encoders)
Rather than allow 64-bit pins for these (done), and add conversion
functions to downconvert to 32 bits, (done) _Then_ decide which other
components might be fed this (possibly truncated value)  it make more
sense to silently convert all HAL pins to the larger types.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] 2.10 Proposals

[Jon E. <el...@pi...>]

On 10/29/25 11:00, Bertho Stultiens wrote:
> On 10/29/25 12:34 AM, andy pugh wrote:
>> 1) Convert all int HAL pins to 64-bit.
>
> This will need *a lot* of work because code written for 
> 32-bit uses tricks and whatnot that are not necessarily 
> compatible with 64-bit. Each and every driver needs to be 
> checked, line for line, that it will work without problems 
> and as advertised. Especially tricky are expected implicit 
> truncation in 32-bit word operations. Each instance must 
> be found and properly re-coded for 64-bit.
Yes, this is what I'm concerned about.  How does a negative 
signed 32-bit value get converted to 64-bit?  There are 
32-bit encoder counts that are signed and can go negative.  
You need to know whether to sign extend it or just pad with 
high-order zeroes.

Jon

Re: [Emc-developers] 2.10 Proposals

[Robert S. <rm...@un...>]

Am Mittwoch, dem 29.10.2025 um 09:17 -0700 schrieb Peter Wallace:
> 
> Yes, many components/drivers have parameters rather than pins for
> this reason.
> 
> In many cases, parameters are not expected to change at run time and
> if 
> changed may cause issues.
> 
> 

Even now you can change parameters at runtime ("setp" in halcmd)

It's not like the concept of a parameter will be removed. It is a HAL-
internal change that will allow the code to get rid of a bunch of
pin/parameter checks und duplicated slightly different code.

rene_dev could probably tell a bit more...

Re: [Emc-developers] 2.10 Proposals

[Robert S. <rm...@un...>]

Am Mittwoch, dem 29.10.2025 um 17:00 +0100 schrieb Bertho Stultiens:
> On 10/29/25 12:34 AM, andy pugh wrote:
> > 1) Convert all int HAL pins to 64-bit.
> 
> This will need *a lot* of work because code written for 32-bit uses 
> tricks and whatnot that are not necessarily compatible with 64-bit.
> Each 
> and every driver needs to be checked, line for line, that it will
> work 
> without problems and as advertised. Especially tricky are expected 
> implicit truncation in 32-bit word operations. Each instance must be 
> found and properly re-coded for 64-bit.

I don't think that there actually is that much code that relies on such
behaviour, see the comment from andy regarding usage of
"signed/unsigned". 

And IMHO relying on undefined behaviour (in the C/C++ language lawyer
sense) like signed overflow is a bug that needs to be fixed, because
sooner or later, some new compiler with additional "insights" into the
code will optimize away such code (or stuff that depends on the
undefined result).

> 
> > 2) Do away with HAL parameters. Convert them all to full pins.
> 
> Even though (most) parameters are located in shared memory, there is
> a 
> real difference between pin and parameter access. Pins are always 
> indirect variables (must be dereferenced) in the HAL component,
> whereas 
> parameters are direct variables. Converting parameters into pins adds
> an 
> indirection and doubles the amount of shared memory accesses for any 
> operation.
> 

in one typical 1kHz servo period we have O(millions) intructions on
contemporary CPUs, even on "small" ones like arm cortex-Axx like in
RPIs. a few hundred additional cycles won't affect anything.

The problem is if some code misses to reserve memory for the
parameters, that situation may be tricky to debug.


and to be clear, both changes will be "internal", so not even writers
of drivers / components will notice very much if anything at all.

Re: [Emc-developers] 2.10 Proposals

[Robert S. <rm...@un...>]

Am Mittwoch, dem 29.10.2025 um 17:03 +0100 schrieb nk...@nk...:
> 
> Have to disagree to make all hal pins the same type. Type checking is
> general something good then possible. This is a step in opposite
> direction.
> 
> Nicklas Karlsson

type checking won't be removed.

Re: [Emc-developers] 2.10 Proposals

[Robert S. <rm...@un...>]

Am Mittwoch, dem 29.10.2025 um 10:43 -0500 schrieb Jon Elson:
> On 10/28/25 18:34, andy pugh wrote:
> > There are three things that I would like to see in 2.10, only one
> > of
> > which is likely to be uncontentious.
> > 
> > 1) Convert all int HAL pins to 64-bit.
> >      This has to go in 2.10, if it happens at all.
> Would this require all drivers to be rewritten?

no

Re: [Emc-developers] 2.10 Proposals

[Peter W. <pc...@me...>]

On Wed, 29 Oct 2025, Bertho Stultiens wrote:

> Date: Wed, 29 Oct 2025 17:10:48 +0100
> From: Bertho Stultiens <lc...@va...>
> Reply-To: EMC developers <emc...@li...>
> To: emc...@li...
> Subject: Re: [Emc-developers] 2.10 Proposals
> 
> On 10/29/25 5:03 PM, nk...@nk... wrote:
>> Have to disagree to make all hal pins the same type. Type checking
>> is general something good then possible. This is a step in opposite
>> direction.
> Agree.
>
> Also, my view has always been that pins are dynamic data and parameters are 
> (run-time static) configuration. That would make separation a Good Thing(TM).
>
> -- 
> Greetings Bertho
>
> (disclaimers are disclaimed)
>


Yes, many components/drivers have parameters rather than pins for this reason.

In many cases, parameters are not expected to change at run time and if 
changed may cause issues.

>

Peter Wallace
Mesa Electronics

Re: [Emc-developers] 2.10 Proposals

[Bertho S. <lc...@va...>]

On 10/29/25 5:03 PM, nk...@nk... wrote:
> Have to disagree to make all hal pins the same type. Type checking
> is general something good then possible. This is a step in opposite
> direction.
Agree.

Also, my view has always been that pins are dynamic data and parameters 
are (run-time static) configuration. That would make separation a Good 
Thing(TM).

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] 2.10 Proposals

[<nk...@nk...>]

Have to disagree to make all hal pins the same type. Type checking is general something good then possible. This is a step in opposite direction.

Nicklas Karlsson


Den Onsdag, Oktober 29, 2025 16:43 CET, skrev Jon Elson <el...@pi...>:
 On 10/28/25 18:34, andy pugh wrote:
> There are three things that I would like to see in 2.10, only one of
> which is likely to be uncontentious.
>
> 1) Convert all int HAL pins to 64-bit.
> This has to go in 2.10, if it happens at all.
Would this require all drivers to be rewritten?
>
> 2) Do away with HAL parameters. Convert them all to full pins.
> In theory using parameters saves HAL shared memory as they are
> meant to live in normal memory. In practice
> nearly every HAL component puts both pins and parameters in HAL
> shared memory, so this advantage is
> not realised. René has a branch in which this has been done.
I have no complaint about this one.
> 3) Incorporate the 9-axis blending TP from Tormach Pathpilot.
> I have the code, and have even tried just dropping it in.
> https://github.com/LinuxCNC/linuxcnc/compare/master...Tormach_9_axis
> It's obviously not going to work like that. If anyone wants to
> look at making it all work, that would be great :-)
> That PR serves the purpose of showing what has changed and where.
> I don't know if it's a good place to
> start actually merging though.

This could be a can of worms, and require some rigorous
testing, but sounds like a good idea!

Jon



_______________________________________________
Emc-developers mailing list
Emc...@li...
https://lists.sourceforge.net/lists/listinfo/emc-developers

 

Re: [Emc-developers] 2.10 Proposals

[Bertho S. <lc...@va...>]

On 10/29/25 12:34 AM, andy pugh wrote:
> 1) Convert all int HAL pins to 64-bit.

This will need *a lot* of work because code written for 32-bit uses 
tricks and whatnot that are not necessarily compatible with 64-bit. Each 
and every driver needs to be checked, line for line, that it will work 
without problems and as advertised. Especially tricky are expected 
implicit truncation in 32-bit word operations. Each instance must be 
found and properly re-coded for 64-bit.


> 2) Do away with HAL parameters. Convert them all to full pins.

Even though (most) parameters are located in shared memory, there is a 
real difference between pin and parameter access. Pins are always 
indirect variables (must be dereferenced) in the HAL component, whereas 
parameters are direct variables. Converting parameters into pins adds an 
indirection and doubles the amount of shared memory accesses for any 
operation.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] 2.10 Proposals

[Jon E. <el...@pi...>]

On 10/28/25 18:34, andy pugh wrote:
> There are three things that I would like to see in 2.10, only one of
> which is likely to be uncontentious.
>
> 1) Convert all int HAL pins to 64-bit.
>      This has to go in 2.10, if it happens at all.
Would this require all drivers to be rewritten?
>
> 2) Do away with HAL parameters. Convert them all to full pins.
>      In theory using  parameters saves HAL shared memory as they are
> meant to live in normal memory. In practice
>      nearly every HAL component puts both pins and parameters in HAL
> shared memory, so this advantage is
>     not realised. René has a branch in which this has been done.
I have no complaint about this one.
> 3) Incorporate the 9-axis blending TP from Tormach Pathpilot.
>      I have the code, and have even tried just dropping it in.
>      https://github.com/LinuxCNC/linuxcnc/compare/master...Tormach_9_axis
>      It's obviously not going to work like that. If anyone wants to
> look at making it all work, that would be great :-)
>      That PR serves the purpose of showing what has changed and where.
> I don't know if it's a good place to
>      start actually merging though.

This could be a can of worms, and require some rigorous 
testing, but sounds like a good idea!

Jon

Re: [Emc-developers] 2.10 Proposals

[andy p. <bod...@gm...>]

On Wed, 29 Oct 2025 at 15:06, Robert Schöftner <rm...@un...> wrote:

> https://www.linuxcnc.org/docs/devel/html/man/man9/tpcomp.9.html
>
> not sure if there actually is a pluggable trajectory planner.

OK, that looks like it could be helpful. Though the Tormach code
predates the introduction of pluggable TPs (I think)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] 2.10 Proposals

[Robert S. <rm...@un...>]

Am Mittwoch, dem 29.10.2025 um 12:10 +0000 schrieb andy pugh:
> On Wed, 29 Oct 2025 at 07:57, rodw <ro...@ve...> wrote:
> > 
> > Given the TP is supposed to be a stand alone module, why don't you
> > deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and
> > allow users to experiment with it on real hardware by changing
> > their ini file settings?
> 
> Are you sure this is the case? Which INI file setting?
> 

https://www.linuxcnc.org/docs/devel/html/man/man9/tpcomp.9.html

not sure if there actually is a pluggable trajectory planner.

Re: [Emc-developers] 2.10 Proposals

[andy p. <bod...@gm...>]

On Wed, 29 Oct 2025 at 07:57, rodw <ro...@ve...> wrote:
>
> Given the TP is supposed to be a stand alone module, why don't you deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and allow users to experiment with it on real hardware by changing their ini file settings?

Are you sure this is the case? Which INI file setting?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] 2.10 Proposals

[rodw <ro...@ve...>]

Given the TP is supposed to be a stand alone module, why don't you deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and allow users to experiment with it on real hardware by changing their ini file settings? If it works out before the release of   2.10, you could   optionally retire the existing TP in 2.10 or in 2.11
Rod
 
 
 
On 2025-10-29 17:01, Robert Schöftner  <rm...@un...>  wrote:
> Am Dienstag, dem 28.10.2025 um 23:34 +0000 schrieb andy pugh:
> >  2) Do away with HAL parameters. Convert them all to full pins.
> >      In theory using  parameters saves HAL shared memory as they are
> >  meant to live in normal memory. In practice
> >      nearly every HAL component puts both pins and parameters in HAL
> >  shared memory, so this advantage is
> >     not realised. René has a branch in which this has been done.
>
> Maybe it made sense in the 90ies with single core PCs with 16-ish MB
> RAM to limit unwappable memory-locked shared memory. OTOH even then, a
> CNC controller that runs into swap was a bad idea.
>
> Nowadays with low-end systems being 4-core 16GB RAM machines, i.e. 1000
> times the RAM and on-cpu caches as big as all memory of the 90ies
> machines, the need to conserve shared memory is not that pressing any
> more.
>
>
> I tested that branch in July but couldn't yet get it to work on real
> hardware (and then ran out of spare time). Implementation details of
> HAL pins make this change somewhat tricky. Converted code needs to
> allocate memory for the parameters, if such allocation is missing, some
> strange behaviour and crashes in the realtime part will result that are
> hard to debug. It seems to work in sim, completes the tests IIRC, but
> that branch needs testing on real hardware.   
>
>
> --   
> Robert Schöftner  <rm...@un...>
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.10 Proposals

[Robert S. <rm...@un...>]

Am Dienstag, dem 28.10.2025 um 23:34 +0000 schrieb andy pugh:
> 2) Do away with HAL parameters. Convert them all to full pins.
>     In theory using  parameters saves HAL shared memory as they are
> meant to live in normal memory. In practice
>     nearly every HAL component puts both pins and parameters in HAL
> shared memory, so this advantage is
>    not realised. René has a branch in which this has been done.

Maybe it made sense in the 90ies with single core PCs with 16-ish MB
RAM to limit unwappable memory-locked shared memory. OTOH even then, a
CNC controller that runs into swap was a bad idea.

Nowadays with low-end systems being 4-core 16GB RAM machines, i.e. 1000
times the RAM and on-cpu caches as big as all memory of the 90ies
machines, the need to conserve shared memory is not that pressing any
more.


I tested that branch in July but couldn't yet get it to work on real
hardware (and then ran out of spare time). Implementation details of
HAL pins make this change somewhat tricky. Converted code needs to
allocate memory for the parameters, if such allocation is missing, some
strange behaviour and crashes in the realtime part will result that are
hard to debug. It seems to work in sim, completes the tests IIRC, but
that branch needs testing on real hardware. 


-- 
Robert Schöftner <rm...@un...>

[Emc-developers] 2.10 Proposals

[andy p. <bod...@gm...>]

There are three things that I would like to see in 2.10, only one of
which is likely to be uncontentious.

1) Convert all int HAL pins to 64-bit.
    This has to go in 2.10, if it happens at all. Master currently
supports both 64-bit and 32-bit int HAL pins. Once
    that is released I believe it is too late to wind it back.
    If it is done now it ought to be almost invisible, and all
existing HAL files should still work.
    Initially the hal_pin_new_s32 and u32 function calls will be
retained, but will create 64-bit pins, and warn that
    hal_pin_signed / unsigned should now be used.
    In a development branch all .comp files in-tree have been updated
(.comp always did say to use signed/unsigned.
    I think jeper foresaw this.)
    One fly in the ointment is Gladevcp (and possibly other VCPs)
which specifically name the pins as _u32 / _s32.
    These would simply become 64-bit, and would still join the hal
nets, but can't have their names changed as this
    would break existing HAL files UNLESS the update-ini script is
expanded to change the pin names in HAL files.
    (Some of this has already been done:
https://github.com/LinuxCNC/linuxcnc/blob/andypugh/long_hal_ints/src/emc/ini/update_ini.py#L553)

2) Do away with HAL parameters. Convert them all to full pins.
    In theory using  parameters saves HAL shared memory as they are
meant to live in normal memory. In practice
    nearly every HAL component puts both pins and parameters in HAL
shared memory, so this advantage is
   not realised. René has a branch in which this has been done.

3) Incorporate the 9-axis blending TP from Tormach Pathpilot.
    I have the code, and have even tried just dropping it in.
    https://github.com/LinuxCNC/linuxcnc/compare/master...Tormach_9_axis
    It's obviously not going to work like that. If anyone wants to
look at making it all work, that would be great :-)
    That PR serves the purpose of showing what has changed and where.
I don't know if it's a good place to
    start actually merging though.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] Installer Script - (was: LinuxCNC 2.9.7 has been released)

[andy p. <bod...@gm...>]

On Mon, 27 Oct 2025 at 23:49, rodw <ro...@ve...> wrote:
>
>
> Does the Linuxcnc ISO work? It should cos the Debian version is a pre release and it was getting 2.9.4. I'll try on a VM tonight

I have just updated the script to require that it be run with sudo,
and taken the explicit "sudos" out of the script. This seems cleaner.
It's on the server under the same name:
www.linuxcnc.org/linuxcnc-install-test.sh

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] Installer Script - (was: LinuxCNC 2.9.7 has been released)

[andy p. <bod...@gm...>]

On Mon, 27 Oct 2025 at 23:49, rodw <ro...@ve...> wrote:
>
> Does the Linuxcnc ISO work? It should cos the Debian version is a pre release and it was getting 2.9.4. I'll try on a VM tonight

Anything installed from the ISO should be fine, it should have the
keys and suchlike already installed.
(note that Trixie needs a new key, let me push that)
https://github.com/LinuxCNC/linuxcnc-live-build/tree/trixie
I built that 2.9.6 Trixie ISO using that config, but I haven't
published it as it is flaky on my test PC (Asroc N100DC. But that is
in some ways a flaky PC...)
Also, I don't like how the splash screen appears in BIOS mode but not
in UEFI. (and I dislike even more that I don't know why)

Back to the subject, the installer script is only intended for
pre-installed Debian systems. (it adds our Apt archive and signing
key, updates apt and installs the relevant 2.9-uspace for the OS)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912