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

[Emc-developers] Reminder - Video Meetup today (Sunday) the 26th of April, 20:00 GMT+2 (CEST)

[Steffen M. <ste...@gm...>]

This effectively means "now". I am sorry for the late notice.

Best,
Steffen

> Gesendet: Sonntag, 12. April 2026 um 19:19
> Von: "Steffen Möller via Emc-developers" <emc...@li...>
> An: emc...@li...
> CC: "Steffen Möller" <ste...@gm...>
> Betreff: [Emc-developers] Emc-developers] Reminder - Video Meetup today (Sunday) the 12th of Aprio, 20:00 GMT+2 (CEST)
>
> Hello,
> 
> https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
> Access code: 869782
> Date: January 4th, 2026
> https://www.timeanddate.com/time/zones/cest
> 20:00
> 
> I am travelling and cannot attend, but I am confident you will have fun without me.
> 
> Best,
> Steffen
> 
> 
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Emc-developers] Reminder - Video Meetup today (Sunday) the 12th of Aprio, 20:00 GMT+2 (CEST)

[Steffen M. <ste...@gm...>]

Hello,

https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782
Date: January 4th, 2026
https://www.timeanddate.com/time/zones/cest
20:00

I am travelling and cannot attend, but I am confident you will have fun without me.

Best,
Steffen

Re: [Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?

[Steffen M. <ste...@gm...>]

Yes, please go ahead.

> Gesendet: Sonntag, 12. April 2026 um 12:30
> Von: "Hans Unzner" <han...@gm...>
> An: emc...@li...
> Betreff: Re: [Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?
>
> Ok, but the conflicts in the component linuxcnc-docs does not affect 
> gmoccapy. Also the linuxcnc component is not locked, so I think it's 
> fine to unlock gmoccapy. Agree?
> 
> Hans
> 
> Am 12.04.26 um 11:58 schrieb Steffen Möller via Emc-developers:
> &gt; Hello,
> &gt;
> &gt; There is some nasty conflict with the Weblate documentation infrastructure for a couple of weeks already that I did not get around to address. Have not addressed anything particular for LinuxCNC/Gmmoccapy.
> &gt;
> &gt; Best,
> &gt; Steffen
> &gt;
> &gt;&gt; Gesendet: Sonntag, 12. April 2026 um 11:08
> &gt;&gt; Von: "Hans Unzner" <han...@gm...>
> &gt;&gt; An: emc...@li...
> &gt;&gt; Betreff: [Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?
> &gt;&gt;
> &gt;&gt; Hi,
> &gt;&gt;
> &gt;&gt; Did somebody lock the Weblate Gmoccapy component? It seems not that
> &gt;&gt; there are problems so I would like to unlock that. Any reasons not to do so?
> &gt;&gt;
> &gt;&gt; Hans
> &gt;&gt;
> &gt;&gt;
> &gt;&gt; _______________________________________________
> &gt;&gt; Emc-developers mailing list
> &gt;&gt; Emc...@li...
> &gt;&gt; https://lists.sourceforge.net/lists/listinfo/emc-developers
> &gt;
> &gt; _______________________________________________
> &gt; Emc-developers mailing list
> &gt; Emc...@li...
> &gt; https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> 
> 
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers</han...@gm...>

Re: [Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?

[Hans U. <han...@gm...>]

Ok, but the conflicts in the component linuxcnc-docs does not affect 
gmoccapy. Also the linuxcnc component is not locked, so I think it's 
fine to unlock gmoccapy. Agree?

Hans

Am 12.04.26 um 11:58 schrieb Steffen Möller via Emc-developers:
> Hello,
>
> There is some nasty conflict with the Weblate documentation infrastructure for a couple of weeks already that I did not get around to address. Have not addressed anything particular for LinuxCNC/Gmmoccapy.
>
> Best,
> Steffen
>
>> Gesendet: Sonntag, 12. April 2026 um 11:08
>> Von: "Hans Unzner" <han...@gm...>
>> An: emc...@li...
>> Betreff: [Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?
>>
>> Hi,
>>
>> Did somebody lock the Weblate Gmoccapy component? It seems not that
>> there are problems so I would like to unlock that. Any reasons not to do so?
>>
>> Hans
>>
>>
>> _______________________________________________
>> Emc-developers mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?

[Steffen M. <ste...@gm...>]

Hello,

There is some nasty conflict with the Weblate documentation infrastructure for a couple of weeks already that I did not get around to address. Have not addressed anything particular for LinuxCNC/Gmmoccapy.

Best,
Steffen

> Gesendet: Sonntag, 12. April 2026 um 11:08
> Von: "Hans Unzner" <han...@gm...>
> An: emc...@li...
> Betreff: [Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?
>
> Hi,
> 
> Did somebody lock the Weblate Gmoccapy component? It seems not that 
> there are problems so I would like to unlock that. Any reasons not to do so?
> 
> Hans
> 
> 
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Weblate LinuxCNC/Gmoccapy locked - why?

[Hans U. <han...@gm...>]

Hi,

Did somebody lock the Weblate Gmoccapy component? It seems not that 
there are problems so I would like to unlock that. Any reasons not to do so?

Hans

Re: [Emc-developers] New RTAI release, want to build linuxcnc debs

[Rob T. <rob...@ao...>]

Andy,  Are you available to answer a few questions via e-mail regarding work you did on LinuxCNC Scorbot-ER-3?Rob

Sent from AOL on Android 
 
  On Tue, Apr 7, 2026 at 5:34 PM, andy pugh<bod...@gm...> wrote:   On Tue, 7 Apr 2026 at 20:18, Alec Ari via Emc-developers
<emc...@li...> wrote:
>
> Did not realize it was as easy as copying over the entire debian folder from andypugh/rtai-2.9, making a few minor changes, adding the new kernel version then of course disabling docs to save a lot of time...

It would be nice to get back to being able to  use the same debian
folder for both, but the two versions have diverged considerably.

-- 
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


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

Re: [Emc-developers] Gentoo LinuxCNC QEMU images

[Alec A. <neo...@ym...>]

Problem solved. Long story short, https://github.com/LinuxCNC/linuxcnc/pull/3925 is required instead of my quick hack to get it to build. axis works! AFTER TWO YEARS!

Alec

On Monday, April 6, 2026 at 12:58:26 PM CDT, Alec Ari via Emc-developers <emc...@li...> wrote: 

https://github.com/NTULINUX/gentoo_backup/releases/tag/kvm

I've been having trouble getting regular axis going on Gentoo, but gmocappy and several other axis screens all work.

Functioning within sim/axis submenu (list not complete):

sim-axis9
lathe
minimal-xyz
ldelta
rdelta

If anyone could try figuring out what the issue is, that'd be great.

LinuxCNC comes pre-installed (master branch) and is shipped with Konqueror and LXQt. Desktop enabled by default, UEFI is not required, serial port and interactive console is available. VirtIO (Virgl) GPU is supported as well as QXL.

Thank you!

Alec


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

Re: [Emc-developers] linuxcnc-ethercat

[Luca T. <lu...@ai...>]

linuxcnc-ethercat user on GitHub should be the place to take over, I'll try to reach out to Scott, see what's his plan. 

On April 11, 2026 6:43:25 AM GMT+08:00, rodw <ro...@ve...> wrote:
>I don't think you can use grotius's repo as Scott Laird's current repo at   https://github.com/linuxcnc-ethercat    includes a lot of enhancements that Grotius will not include.
>Grotius includes a header file from etherlab's Ethercat master repo   https://etherlab.org/en_GB/ethercat   Whilst, it is required to compile, it should not be just copied into the project.
>A better source might be the libethercat-dev package.
> 
>Finally, it ignores the project history. Why not use my fork or anybody elses at random? Scott Laird had permission from the original developer Sasha Itnner to take over the project and developed workflows that published his Deb files to the etherlab repositories. Prior to Scott arriving on the scene, etherlab also had Sasha's consent to host his repo and were doing so before Scott started adding enhancements. Sasha has been active in discussions on Scott's repository in 2026. Sasha tells people on his repo to    use Scotts.    There are only two valid sources should linuxcnc take it over:
>Scott Laird's   https://github.com/linuxcnc-ethercat  
>Luca's   https://github.com/grandixximo/linuxcnc-ethercat  
> 
>I think the preferred course would be work from Scott's and Luca should send his recent and important PR to the new repo. workflows should then publish the deb files to the Linuxcnc repository.
> 
>Rod Webster  
>
> 
>On 2026-04-11 06:31, Amit Goradia  <am...@au...>  wrote:
>> On Tue, Apr 7, 2026 at 6:06 PM Bari  <bar...@gm...>  wrote:
>>
>> >  After 4 months of no replies I'd call that abandoned. How much longer
>> >  should you wait? Fork it publicly and move on with our lives. It's
>> >  trivial to merge later IF the other fork maintainer reappears. People
>> >  get sick or worse, have kids, loose interest, etc etc.
>> >
>> >
>> Bari, your sentence phrasing is really hilarious if you do not parse the
>> comma properly...
>> People get sick or worse, have kids... LOL...
>>
>>
>> >  On 4/7/26 4:04 AM, Luca Toniolo wrote:
>> >   >  Scott has been out for about 4 months, no answers no merging, does
>> >  anyone else have the administration access to the
>> >  linuxcnc-ethercat/linuxcnc-ethercat repo on GitHub? Users on the forum have
>> >  been pointed to my fork, but I am not sure that is proper, Sascha's work is
>> >  not compatible at the moment, need some guidance from a maintainer for
>> >  direction on the project...
>> >   >  _______________________________________________
>> >   >  Emc-developers mailing list
>> >   >  Emc...@li...
>> >   >  https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >
>> >  Luca, I agree with Bari, 4 months with no response can be construed as
>> abandoned. Also, the Go dependencies introduced in this project was a bit
>> of a bother anyways.
>> I'd much prefer to use grotius' fork available at
>> https://codeberg.org/skynet/linuxcnc-ethercat where he moved everything to
>> a CMake file although he lost most of the directory structure.
>> -automata
>>
>>
>> >
>> >  _______________________________________________
>> >  Emc-developers mailing list
>> >  Emc...@li...
>> >  https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >
>>
>> _______________________________________________
>> Emc-developers mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>_______________________________________________
>Emc-developers mailing list
>Emc...@li...
>https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-ethercat

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

I don't think you can use grotius's repo as Scott Laird's current repo at   https://github.com/linuxcnc-ethercat    includes a lot of enhancements that Grotius will not include.
Grotius includes a header file from etherlab's Ethercat master repo   https://etherlab.org/en_GB/ethercat   Whilst, it is required to compile, it should not be just copied into the project.
A better source might be the libethercat-dev package.
 
Finally, it ignores the project history. Why not use my fork or anybody elses at random? Scott Laird had permission from the original developer Sasha Itnner to take over the project and developed workflows that published his Deb files to the etherlab repositories. Prior to Scott arriving on the scene, etherlab also had Sasha's consent to host his repo and were doing so before Scott started adding enhancements. Sasha has been active in discussions on Scott's repository in 2026. Sasha tells people on his repo to    use Scotts.    There are only two valid sources should linuxcnc take it over:
Scott Laird's   https://github.com/linuxcnc-ethercat  
Luca's   https://github.com/grandixximo/linuxcnc-ethercat  
 
I think the preferred course would be work from Scott's and Luca should send his recent and important PR to the new repo. workflows should then publish the deb files to the Linuxcnc repository.
 
Rod Webster  

 
On 2026-04-11 06:31, Amit Goradia  <am...@au...>  wrote:
> On Tue, Apr 7, 2026 at 6:06 PM Bari  <bar...@gm...>  wrote:
>
> >  After 4 months of no replies I'd call that abandoned. How much longer
> >  should you wait? Fork it publicly and move on with our lives. It's
> >  trivial to merge later IF the other fork maintainer reappears. People
> >  get sick or worse, have kids, loose interest, etc etc.
> >
> >
> Bari, your sentence phrasing is really hilarious if you do not parse the
> comma properly...
> People get sick or worse, have kids... LOL...
>
>
> >  On 4/7/26 4:04 AM, Luca Toniolo wrote:
> >   >  Scott has been out for about 4 months, no answers no merging, does
> >  anyone else have the administration access to the
> >  linuxcnc-ethercat/linuxcnc-ethercat repo on GitHub? Users on the forum have
> >  been pointed to my fork, but I am not sure that is proper, Sascha's work is
> >  not compatible at the moment, need some guidance from a maintainer for
> >  direction on the project...
> >   >  _______________________________________________
> >   >  Emc-developers mailing list
> >   >  Emc...@li...
> >   >  https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> >  Luca, I agree with Bari, 4 months with no response can be construed as
> abandoned. Also, the Go dependencies introduced in this project was a bit
> of a bother anyways.
> I'd much prefer to use grotius' fork available at
> https://codeberg.org/skynet/linuxcnc-ethercat where he moved everything to
> a CMake file although he lost most of the directory structure.
> -automata
>
>
> >
> >  _______________________________________________
> >  Emc-developers mailing list
> >  Emc...@li...
> >  https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] INI file variable names and sections

[Chris M. <chr...@ho...>]

When Andy added the spindle section and code, he added the deprecated warnings.
He didn't communicate to the GUI maintainers that this was done or why - maybe he forgot.
Either way as Hans mentioned the GUI can further limit the manual controlled limits of the spindle.
So you can limit the manual controlled speed differently from the auto mode speed.
I could certainly see an argument for defaulting to the spindle section if the display section is missing.

Chris
________________________________
From: Bertho Stultiens <lc...@va...>
Sent: April 7, 2026 9:06 AM
To: emc...@li... <emc...@li...>
Subject: Re: [Emc-developers] INI file variable names and sections

On 3/30/26 3:21 AM, Chris Morley wrote:
> Thanks. python/common/iniinfo.py  uses configparser for reading MDI
> commands, as an example of the needed behavior.
There are some questions here about iniinfo.py (and qt_istat.py).

In lines 369..396 of lib/python/common/iniinfo.py there are queries
about the spindle(s) reading ini-values from the [DISPLAY] section in
form (with n replaced by the spindle number being processed):
- DEFAULT_SPINDLE_n_SPEED
- MIN_SPINDLE_n_SPEED
- MAX_SPINDLE_n_SPEED
(equivalent also found in qt_istat.py)

These and more spindle ini entries seem to be deprecated in the docs
(docs/src/config/ini-config.adoc), but there is no alternative
implemented in the IStat class. It is supposed to use values in
[SPINDLE_n] sections according to the docs.

The values in the [DISPLAY] section are not read by the
emc/ini/inispindle.cc file. This looks like a disparity and confusion
between UIs and LinuxCNC internals.

--
Greetings Bertho

(disclaimers are disclaimed)



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

Re: [Emc-developers] New RTAI release, want to build linuxcnc debs

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

On Tue, 7 Apr 2026 at 20:18, Alec Ari via Emc-developers
<emc...@li...> wrote:
>
> Did not realize it was as easy as copying over the entire debian folder from andypugh/rtai-2.9, making a few minor changes, adding the new kernel version then of course disabling docs to save a lot of time...

It would be nice to get back to being able to  use the same debian
folder for both, but the two versions have diverged considerably.

-- 
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] INI file variable names and sections

[Hans U. <han...@gm...>]

Am 07.04.26 um 11:06 schrieb Bertho Stultiens:
> On 3/30/26 3:21 AM, Chris Morley wrote:
>> Thanks. python/common/iniinfo.py  uses configparser for reading MDI
>> commands, as an example of the needed behavior.
> There are some questions here about iniinfo.py (and qt_istat.py).
>
> In lines 369..396 of lib/python/common/iniinfo.py there are queries 
> about the spindle(s) reading ini-values from the [DISPLAY] section in 
> form (with n replaced by the spindle number being processed):
> - DEFAULT_SPINDLE_n_SPEED
> - MIN_SPINDLE_n_SPEED
> - MAX_SPINDLE_n_SPEED
> (equivalent also found in qt_istat.py)
>
> These and more spindle ini entries seem to be deprecated in the docs 
> (docs/src/config/ini-config.adoc), but there is no alternative 
> implemented in the IStat class. It is supposed to use values in 
> [SPINDLE_n] sections according to the docs.
>
> The values in the [DISPLAY] section are not read by the 
> emc/ini/inispindle.cc file. This looks like a disparity and confusion 
> between UIs and LinuxCNC internals.
>
The idea is that the values of the DISPLAY section are read by the GUI 
e.g. to scale bars or set defaults/limits for jogging etc.
The values of SPINDLE_N, TRAJ, JOINT_N, AXIS_N are supposed be used to 
set parameters for the hardware.

Re: [Emc-developers] New RTAI release, want to build linuxcnc debs

[Alec A. <neo...@ym...>]

Did not realize it was as easy as copying over the entire debian folder from andypugh/rtai-2.9, making a few minor changes, adding the new kernel version then of course disabling docs to save a lot of time...

Alec

[Emc-developers] New RTAI release, want to build linuxcnc debs

[Alec A. <neo...@ym...>]

New kernel debs:

https://github.com/NTULINUX/RTAI/releases/tag/v5.3.4

Now that the crashing has been fixed in LinuxCNC, awaiting https://github.com/LinuxCNC/linuxcnc/pull/3901 to be merged into `master` branch, I'd like to build LinuxCNC debs, but the RTAI debian/* files in LinuxCNC are still not present.

Andy, I know you still have this branch:

https://github.com/LinuxCNC/linuxcnc/tree/andypugh/2.9-rtai

Is it possible to rebase it against master once the floating-point fixes are merged?

Thanks,

Alec

Re: [Emc-developers] linuxcnc-ethercat

[Amit G. <am...@au...>]

On Tue, Apr 7, 2026 at 6:06 PM Bari <bar...@gm...> wrote:

> After 4 months of no replies I'd call that abandoned. How much longer
> should you wait? Fork it publicly and move on with our lives. It's
> trivial to merge later IF the other fork maintainer reappears. People
> get sick or worse, have kids, loose interest, etc etc.
>
>
Bari, your sentence phrasing is really hilarious if you do not parse the
comma properly...
People get sick or worse, have kids... LOL...


> On 4/7/26 4:04 AM, Luca Toniolo wrote:
> > Scott has been out for about 4 months, no answers no merging, does
> anyone else have the administration access to the
> linuxcnc-ethercat/linuxcnc-ethercat repo on GitHub? Users on the forum have
> been pointed to my fork, but I am not sure that is proper, Sascha's work is
> not compatible at the moment, need some guidance from a maintainer for
> direction on the project...
> > _______________________________________________
> > Emc-developers mailing list
> > Emc...@li...
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> Luca, I agree with Bari, 4 months with no response can be construed as
abandoned. Also, the Go dependencies introduced in this project was a bit
of a bother anyways.
I'd much prefer to use grotius' fork available at
https://codeberg.org/skynet/linuxcnc-ethercat where he moved everything to
a CMake file although he lost most of the directory structure.
-automata


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

Re: [Emc-developers] linuxcnc-ethercat

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

On Tue, 7 Apr 2026 at 13:37, Bari <bar...@gm...> wrote:
>
> After 4 months of no replies I'd call that abandoned. How much longer
> should you wait?

He appears to be active in other projects, which rather points to
abandonment of linuxcnc-ethercat.

If we fork it into the LinuxCNC org then at least we have some
redundancy in maintainers.

-- 
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] linuxcnc-ethercat

[Bari <bar...@gm...>]

After 4 months of no replies I'd call that abandoned. How much longer 
should you wait? Fork it publicly and move on with our lives. It's 
trivial to merge later IF the other fork maintainer reappears. People 
get sick or worse, have kids, loose interest, etc etc.

On 4/7/26 4:04 AM, Luca Toniolo wrote:
> Scott has been out for about 4 months, no answers no merging, does anyone else have the administration access to the linuxcnc-ethercat/linuxcnc-ethercat repo on GitHub? Users on the forum have been pointed to my fork, but I am not sure that is proper, Sascha's work is not compatible at the moment, need some guidance from a maintainer for direction on the project...
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] INI file variable names and sections

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

On 3/30/26 3:21 AM, Chris Morley wrote:
> Thanks. python/common/iniinfo.py  uses configparser for reading MDI
> commands, as an example of the needed behavior.
There are some questions here about iniinfo.py (and qt_istat.py).

In lines 369..396 of lib/python/common/iniinfo.py there are queries 
about the spindle(s) reading ini-values from the [DISPLAY] section in 
form (with n replaced by the spindle number being processed):
- DEFAULT_SPINDLE_n_SPEED
- MIN_SPINDLE_n_SPEED
- MAX_SPINDLE_n_SPEED
(equivalent also found in qt_istat.py)

These and more spindle ini entries seem to be deprecated in the docs 
(docs/src/config/ini-config.adoc), but there is no alternative 
implemented in the IStat class. It is supposed to use values in 
[SPINDLE_n] sections according to the docs.

The values in the [DISPLAY] section are not read by the 
emc/ini/inispindle.cc file. This looks like a disparity and confusion 
between UIs and LinuxCNC internals.

-- 
Greetings Bertho

(disclaimers are disclaimed)

[Emc-developers] linuxcnc-ethercat

[Luca T. <lu...@ai...>]

Scott has been out for about 4 months, no answers no merging, does anyone else have the administration access to the linuxcnc-ethercat/linuxcnc-ethercat repo on GitHub? Users on the forum have been pointed to my fork, but I am not sure that is proper, Sascha's work is not compatible at the moment, need some guidance from a maintainer for direction on the project...

[Emc-developers] Gentoo LinuxCNC QEMU images

[Alec A. <neo...@ym...>]

https://github.com/NTULINUX/gentoo_backup/releases/tag/kvm

I've been having trouble getting regular axis going on Gentoo, but gmocappy and several other axis screens all work.

Functioning within sim/axis submenu (list not complete):

sim-axis9
lathe
minimal-xyz
ldelta
rdelta

If anyone could try figuring out what the issue is, that'd be great.

LinuxCNC comes pre-installed (master branch) and is shipped with Konqueror and LXQt. Desktop enabled by default, UEFI is not required, serial port and interactive console is available. VirtIO (Virgl) GPU is supported as well as QXL.

Thank you!

Alec

Re: [Emc-developers] INI file variable names and sections

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

On 4/3/26 10:31 AM, Luca Toniolo wrote:
> Somewhat related to the INI parser.
> Yesterday I was trying to test parport on RTAI had a look at the
> configs that were available, they are a total disaster.
There are probably many more to find ;-)


> One interesting thing, you might want to be aware, not sure if you 
> already took a look when coding your new parser etch-servo has a
> weird issues> [TRAJ]
> HOME = 0 0
> Fails to start, because it's expecting three values, even though the 
> lather only has two axis Not really part of the ini parser, but
> initraj.cc , are you having a look there as well? Or should I?
This is, as you noted, not an issue with the ini-parser, but with how 
ini values are parsed. I did notice it to be wrong and very inflexible. 
It would only test/split 6 values and only set 3 (XYZ).

But, this particular piece of code has been changed to do:
1. read [TRAJ]HOME as string
2. split on " \t"
3. for each part
   - convert to double
   - assign to pose XYZABCUVW in sequence

When you only have two pieces, then it will only assign those two to XY.

It does pose a problem with systems that have XZA axes, but you can fake 
the Y with a zero, I guess. Double axis systems like XXYYZ will have all 
their equally named axes at the same position, but that should be right.

I attached my version of the modified code for you to check out (line 
240...), but it is still preliminary and there may be minor adjustments.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] INI file variable names and sections

[Luca T. <lu...@ai...>]

Good Morning Bertho,

Somewhat related to the INI parser.

Yesterday I was trying to test parport on RTAI had a look at the configs that were available, they are a total disaster.

One interesting thing, you might want to be aware, not sure if you already took a look when coding your new parser

etch-servo has a weird issues

[TRAJ]
HOME = 0 0 

Fails to start, because it's expecting three values, even though the lather only has two axis

Not really part of the ini parser, but initraj.cc , are you having a look there as well? Or should I?

Luca


On March 29, 2026 5:05:10 PM GMT+08:00, Bertho Stultiens <lc...@va...> wrote:
>On 3/29/26 3:31 AM, Chris Morley wrote:
>> A good portion of INI entries are parsed by python directly. We
>> would need to check if any of the rules are bent there. One rule i
>> think that's bent is finding multiple entries under one heading that
>> are the same spelling. Another is getting all the entries under one
>> heading as a list.
>I think (hope) most python ini parsing is done through the ini-interface in module linuxcnc.ini (emc/usr_intf/axis/extensions/emcmodule.cc). This will simply invoke the new parser. But I still have to go through all the front-end code to fix consistency things.
>
>The reason for creating the new parser was the complete lack of consistency when reading boolean values (see https://github.com/LinuxCNC/linuxcnc/issues/3863).
>
>
>> I dont think we restrict the entry name at all. I would need to check if pythons configparser has default restrictions.
>Good point. I'd also need to check where/if it is used and how it behaves. A real problem might be different syntax behaviour. Especially string handling. Also, it probably does not support includes, which is now part of the parser.
>
>If there are any instances of /other/ ini parsers used in the code, then they need to be changed to the LinuxCNC version. It is a real pain to use different parsers and expect consistency, which was the problem in the first place...
>
>-- 
>Greetings Bertho
>
>(disclaimers are disclaimed)
>
>
>
>_______________________________________________
>Emc-developers mailing list
>Emc...@li...
>https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 5.4 kernel tree still active (Oracle) Possible RTAI target

[Alec A. <neo...@ym...>]

Sorry about that, my rtai-modules package was broken, fixed it, please re-download the new rtai-modules deb, and I will also bump the CPU count to 16 by default tomorrow.

On Wednesday, April 1, 2026 at 01:50:32 AM CDT, Luca Toniolo <lu...@ai...> wrote: 





Hey Alec,
Two things to report:
First, rtai_hal.ko was refusing to load because my system has 12 cores 
but the package was built with CONFIG_RTAI_CPUS=8. The error message was 
misleading ("Operation not permitted"), but dmesg showed "RTAI 
CONFIGURED WITH LESS THAN NUM ONLINE CPUS". Fixed it by booting with 
maxcpus=8.
After that, the RTAI testsuite works fine:
```
RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
RTD| -655| -655| -81| 5586| 5586| 0
```
The problem is rtai_math.ko. It fails to load:
```
rtai_math: Unknown symbol __math_divzero (err -2)
rtai_math: Unknown symbol __log_data (err -2)
rtai_math: Unknown symbol fma (err -2)
```
I ran nm on it and those three symbols are listed as U (undefined). 
They're internal musl helpers that get called by the higher-level math 
functions (pow, log, etc.) but they weren't linked into the module. The 
musl code itself is fine, the issue is just that these objects didn't 
make it into rtai_math.ko during the build.
The RTAI testsuite doesn't load rtai_math.ko so it passes, but LinuxCNC 
needs it for all its RT modules (motmod, tpmod). Without it nothing can run.
I can see from your screenshots that latency-histogram runs on your 
system with HAL threads, so rtai_math.ko must load fine there. On my 
Trixie install (GCC 14.2.0-19, same as the kernel headers) it doesn't. 
What distro/version did you build the packages on? Maybe there's a 
binutils or linker difference causing the symbols not to get pulled in.
Luca


On 4/1/26 1:13 PM, Alec Ari via Emc-developers wrote:
> Yes, 5.4.280 works but parallel cards have not yet been tested with it. The reason I went with musl is due to correctness and portability. Adding glibc to kernel space is overkill and adds way too much. You actually need to strip out a lot from the glibc library in order for it to work whereas musl is a lot more modular.
>
> Don't worry about the musl math library at all, that stuff is well tested and true.
>
> Two things... Make sure the RTAI testsuite works:
>
> sudo /usr/realtime-5.4.280-rtai-amd64/testsuite/run
>
> and `halrun -U` should unload the RTAI modules.
>
> On Wednesday, April 1, 2026 at 12:03:12 AM CDT, Luca Toniolo<lu...@ai...> wrote:
>
>
>
>
>
> is the 5.4.280 supposed to work? I cannot fix the rtai_hal.ko not loading
>
> Why are you not using Trixie glibc/libm? Was the package not for debian 13?
>
>
> On April 1, 2026 12:54:03 PM GMT+08:00, Alec Ari via Emc-developers<emc...@li...> wrote:
>> Not very... Each major kernel release requires a lot of work. IPIPE is from Xenomai but slightly modified for RTAI which is then called "hal-linux."AlecOn Tuesday, March 31, 2026 at 07:34:33 PM CDT, andy pugh<bod...@gm...> wrote: On Tue, 31 Mar 2026 at 22:39, Alec Ari via Emc-developers<emc...@li...> wrote:Sadly, IPIPE isn't patched that far ahead. 5.4 or 4.19 are the only choices right now.Who does IPIPE? How non-portable is the patch between kernels?
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc...@li...
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 5.4 kernel tree still active (Oracle) Possible RTAI target

[Luca T. <lu...@ai...>]

Hey Alec,
Two things to report:
First, rtai_hal.ko was refusing to load because my system has 12 cores 
but the package was built with CONFIG_RTAI_CPUS=8. The error message was 
misleading ("Operation not permitted"), but dmesg showed "RTAI 
CONFIGURED WITH LESS THAN NUM ONLINE CPUS". Fixed it by booting with 
maxcpus=8.
After that, the RTAI testsuite works fine:
```
RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
RTD| -655| -655| -81| 5586| 5586| 0
```
The problem is rtai_math.ko. It fails to load:
```
rtai_math: Unknown symbol __math_divzero (err -2)
rtai_math: Unknown symbol __log_data (err -2)
rtai_math: Unknown symbol fma (err -2)
```
I ran nm on it and those three symbols are listed as U (undefined). 
They're internal musl helpers that get called by the higher-level math 
functions (pow, log, etc.) but they weren't linked into the module. The 
musl code itself is fine, the issue is just that these objects didn't 
make it into rtai_math.ko during the build.
The RTAI testsuite doesn't load rtai_math.ko so it passes, but LinuxCNC 
needs it for all its RT modules (motmod, tpmod). Without it nothing can run.
I can see from your screenshots that latency-histogram runs on your 
system with HAL threads, so rtai_math.ko must load fine there. On my 
Trixie install (GCC 14.2.0-19, same as the kernel headers) it doesn't. 
What distro/version did you build the packages on? Maybe there's a 
binutils or linker difference causing the symbols not to get pulled in.
Luca


On 4/1/26 1:13 PM, Alec Ari via Emc-developers wrote:
> Yes, 5.4.280 works but parallel cards have not yet been tested with it. The reason I went with musl is due to correctness and portability. Adding glibc to kernel space is overkill and adds way too much. You actually need to strip out a lot from the glibc library in order for it to work whereas musl is a lot more modular.
>
> Don't worry about the musl math library at all, that stuff is well tested and true.
>
> Two things... Make sure the RTAI testsuite works:
>
> sudo /usr/realtime-5.4.280-rtai-amd64/testsuite/run
>
> and `halrun -U` should unload the RTAI modules.
>
> On Wednesday, April 1, 2026 at 12:03:12 AM CDT, Luca Toniolo<lu...@ai...> wrote:
>
>
>
>
>
> is the 5.4.280 supposed to work? I cannot fix the rtai_hal.ko not loading
>
> Why are you not using Trixie glibc/libm? Was the package not for debian 13?
>
>
> On April 1, 2026 12:54:03 PM GMT+08:00, Alec Ari via Emc-developers<emc...@li...> wrote:
>> Not very... Each major kernel release requires a lot of work. IPIPE is from Xenomai but slightly modified for RTAI which is then called "hal-linux."AlecOn Tuesday, March 31, 2026 at 07:34:33 PM CDT, andy pugh<bod...@gm...> wrote: On Tue, 31 Mar 2026 at 22:39, Alec Ari via Emc-developers<emc...@li...> wrote:Sadly, IPIPE isn't patched that far ahead. 5.4 or 4.19 are the only choices right now.Who does IPIPE? How non-portable is the patch between kernels?
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers