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

[Emc-developers] Bug#1129683: linuxcnc-uspace: Demote python3-poppler-qt5 to Suggests

[Bastian G. <ba...@de...>]

Control: forwarded -1 https://github.com/LinuxCNC/linuxcnc/commit/601d19083ee495c818853dabc1e3d9d99fa12fa4
Control: tags -1 fixed-upstream

[Emc-developers] Processed: linuxcnc-uspace: Demote python3-poppler-qt5 to Suggests

[Debian B. T. S. <ow...@bu...>]

Processing control commands:

> forwarded -1 https://github.com/LinuxCNC/linuxcnc/commit/601d19083ee495c818853dabc1e3d9d99fa12fa4
Bug #1129683 [linuxcnc-uspace] linuxcnc-uspace: Demote python3-poppler-qt5 to Suggests
Set Bug forwarded-to-address to 'https://github.com/LinuxCNC/linuxcnc/commit/601d19083ee495c818853dabc1e3d9d99fa12fa4'.
> tags -1 fixed-upstream
Bug #1129683 [linuxcnc-uspace] linuxcnc-uspace: Demote python3-poppler-qt5 to Suggests
Added tag(s) fixed-upstream.

-- 
1129683: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1129683
Debian Bug Tracking System
Contact ow...@bu... with problems

[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