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

Re: [Emc-developers] branch protection turned on

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

Just posting this here for visibility, this was posted on the Meeting 
Agenda on gh by Greg Carl aka snowgoer540, and it is relevant to the 
discussion here

you can find the original here

https://github.com/LinuxCNC/linuxcnc/discussions/4566

PS:
Anyone that can make it to the Sunday meeting is welcome to join.

---
snowgoer540 yesterday

With regard to #3 <https://github.com/LinuxCNC/linuxcnc/pull/3>, I 
apologize, as I won’t be able to attend the meeting. I know I wasn’t 
asked to attend - I found out about it through the developer email chain 
on the SourceForge website - but I wanted to at least have some 
representation, particularly since it appears that others may be coming 
into the discussion with an established agenda.

What most concerns me is not that Chris made a perceived mistake (he did 
have plenty of discussion surrounding the changes from what I saw). 
Mistakes happen, and I have no objection to discussing how changes to 
the project should be reviewed going forward. What concerns me is the 
way a long-time contributor to this project has been treated as a result.

There are not many active developers left on this project, and there are 
even fewer who have been around long enough to understand the history 
and context behind the code. That institutional knowledge has value, and 
I don't think it should be dismissed.
I also find the response to Chris' mistake difficult to reconcile with 
the history of the project. The person who enabled branch protection and 
reverted the changes unilaterally has himself committed a number of very 
large changes to the codebase with little or no advance discussion, and 
in some cases those changes subsequently sat for a year or more with 
significant issues still outstanding. None of those changes went through 
a PR.

For some examples, look at the discussion surrounding commits 7ebe7d9 
<https://github.com/LinuxCNC/linuxcnc/commit/7ebe7d91fced459729c84a4265556692010379c9>, 
9d79c2a 
<https://github.com/LinuxCNC/linuxcnc/commit/9d79c2aa23e6e6762dfc32b4ad7c4b7d219e9ea4>, 
9a45ed9 
<https://github.com/LinuxCNC/linuxcnc/commit/9a45ed94f75f2cef5cef29fd92d859d7ab0662a9>, 
and 13b52cb 
<https://github.com/LinuxCNC/linuxcnc/commit/13b52cb9377b7e998c4efd29f2616bfa737f2bda>. 
The point isn't to dredge up the past, it is to point out that the 
standard now apparently being applied to Chris’ commits only seems to 
apply since someone didn’t like having their toes stepped on.

I am certainly not opposed to code review. I have opened plenty of PRs 
for changes where I wanted another set of eyes. I also have commits 
where I discussed the changes with other developers privately before 
committing them. I have no problem with review when it is actually 
useful and appropriate. Collaboration definitely moves things forward.

What I do object to is changing the rules without discussion and then 
treating someone as though they violated an established process when 
that process did not previously exist or was not previously enforced.

There is also a long-standing precedent for having a maintainer 
responsible for a particular portion of the project. As long as I have 
been contributing, GUIs have effectively operated that way. The users 
generally do not care whether a particular GUI feature was implemented 
through a PR, a direct commit, or some other mechanism. They cared that 
the feature worked and that bugs were fixed.
For issues in the main portion of the project, changes were generally 
handled through PRs, or by the person responsible for that particular 
section of the code. That division of responsibility existed for a 
reason: people who maintain a particular part of the project develop an 
understanding of its history, architecture, and the consequences of 
seemingly small changes.

If the project now wants to move to a different development model, I am 
willing to discuss that. But I don't think it is reasonable to silently 
change the process, apply it retroactively, selectively, and then use 
someone's mistake as justification for the change.

-----

On 9/18/26 2:19 AM, Chris Morley wrote:
> My work flow has always to push directly.At one time that was the standard way to do it.
> I have been in this project for 20 odd years.
>
> I have done a few pr for ease of people to look at or test with. I usually push these direct after but not always.
>
> There has been no formal change to prs only. From memory it was discussed but never agreed on.
>
> In this case push direct or pr would not of changed what happened. I would have rebased and force pushed to pr and then merged.
>
> The real problem seems to be it was a surprise that I was going to push my own case. Which as i state is beem standard forever and noone has complained.
>
> In my mind why wouldn't  I ? I'd  fixed all issues with the only person who wanted changes. I said I was read to put this code in. There were mo conflicts. I still don't know exactly what the problem with the branch is.
>
> Now I would be more direct about my intension to push next time for sure, so I'll own that.
>
> The reason I did a pr is so other could look at it. Hans and I went through quite a few changes and compromise. I thought the process worked well.
>
> The issue seems to be conflicts in code in gmoccapy. There are going to be conflicts if we are working on the same code. I have fixed conflicts many times in this process. This is the process in a healthy project.
>
> Then you guys 'beat' me up on github, pulled my code and locked everyone out of pushing with no formal discussion.
>
> I take it from that, that if my code cause your code conflicts that is not allowed but if your code causes conflicts in mine that's fine.
>
> In 23 years I think I've made 1 big mistake. It happens from time to time other have too.
>
> Most of my work is in guis, particularly qtdragon .I dont want to have to find  a buddy to push my work every time.
> Sent from my Galaxy
> Finally please dont think that since most of you do something, that that is now policy.
> If you want to change policy let's discuss and try to agree and certainly no beat someone up for doing something that you could see  was normal for them.
>
> Thanks Chris
>
>
> -------- Original message --------
> From: andy pugh<bod...@gm...>
> Date: 2026-09-17 6:17 a.m. (GMT-08:00)
> To: EMC developers<emc...@li...>
> Subject: Re: [Emc-developers] branch protection turned on
>
> On Thu, 17 Sept 2026 at 13:44, Luca Toniolo<lu...@ai...> wrote:
>
>> I ask because most of my direct pushes have been minor doc fixes and such, where a PR is mostly clicking through ceremony.
> Do you push directly to master? Or via a PR? It's perfectly possible
> to create a PR and then merge it yourself for trivial /
> uncontroversial changes.
>
> Historically we had our own git server, and those devs that had access
> pushed their changes directly. Those that did not have access would
> have to email a patch to a core dev to be reviewed and (maybe) merged,
> We then moved to GitHub and those same developers retained the ability
> to push directly. This made things simpler and more transparent for
> contributors without push access.
>
> We haven't previously insisted on PRs, and I quite often push to wlo
> without a PR.
>
> I think it's probably better to go via a PR, mainly for consistency,
> even if it is self-merged by the developer.
>
> --
> 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
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Video Developer Meeting Sunday 2026-09-27 20:00 CEST

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

Hi,

It's been another two weeks and this is a reminder/invitation.

Agenda: https://github.com/LinuxCNC/linuxcnc/discussions/4566

According to our bi-weekly schedule alternating between "early" and 
"late", this video meeting is this Sunday 2026-Sep-27 at 20:00 CEST.

https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=9&day=27&hour=18&min=0&sec=0&p1=319&p2=236&p3=240&p4=136&p5=165&p6=256

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] branch protection turned on

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

My work flow has always to push directly.At one time that was the standard way to do it.
I have been in this project for 20 odd years.

I have done a few pr for ease of people to look at or test with. I usually push these direct after but not always.

There has been no formal change to prs only. From memory it was discussed but never agreed on.

In this case push direct or pr would not of changed what happened. I would have rebased and force pushed to pr and then merged.

The real problem seems to be it was a surprise that I was going to push my own case. Which as i state is beem standard forever and noone has complained.

In my mind why wouldn't  I ? I'd  fixed all issues with the only person who wanted changes. I said I was read to put this code in. There were mo conflicts. I still don't know exactly what the problem with the branch is.

Now I would be more direct about my intension to push next time for sure, so I'll own that.

The reason I did a pr is so other could look at it. Hans and I went through quite a few changes and compromise. I thought the process worked well.

The issue seems to be conflicts in code in gmoccapy. There are going to be conflicts if we are working on the same code. I have fixed conflicts many times in this process. This is the process in a healthy project.

Then you guys 'beat' me up on github, pulled my code and locked everyone out of pushing with no formal discussion.

I take it from that, that if my code cause your code conflicts that is not allowed but if your code causes conflicts in mine that's fine.

In 23 years I think I've made 1 big mistake. It happens from time to time other have too.

Most of my work is in guis, particularly qtdragon .I dont want to have to find  a buddy to push my work every time.
Sent from my Galaxy
Finally please dont think that since most of you do something, that that is now policy.
If you want to change policy let's discuss and try to agree and certainly no beat someone up for doing something that you could see  was normal for them.

Thanks Chris


-------- Original message --------
From: andy pugh <bod...@gm...>
Date: 2026-09-17 6:17 a.m. (GMT-08:00)
To: EMC developers <emc...@li...>
Subject: Re: [Emc-developers] branch protection turned on

On Thu, 17 Sept 2026 at 13:44, Luca Toniolo <lu...@ai...> wrote:

> I ask because most of my direct pushes have been minor doc fixes and such, where a PR is mostly clicking through ceremony.

Do you push directly to master? Or via a PR? It's perfectly possible
to create a PR and then merge it yourself for trivial /
uncontroversial changes.

Historically we had our own git server, and those devs that had access
pushed their changes directly. Those that did not have access would
have to email a patch to a core dev to be reviewed and (maybe) merged,
We then moved to GitHub and those same developers retained the ability
to push directly. This made things simpler and more transparent for
contributors without push access.

We haven't previously insisted on PRs, and I quite often push to wlo
without a PR.

I think it's probably better to go via a PR, mainly for consistency,
even if it is self-merged by the developer.

--
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] branch protection turned on

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

>> Do you push directly to master? Or via a PR? It's perfectly possible 
>> to create a PR and then merge it yourself for trivial / uncontroversial
>> changes.> Pushing directly to master It's not my usual or preferred workflow, but
> I did do it a couple of times, on locally tested uncontroversial changes
> I didn't want to wait the CI for. PR and self merge works well for
> me, I don't really have a dog in this fight... But I keep track of the
> commits, I think (but might be wrong) every active dev other than Bertho
> has pushed to master on a few occasions, Chris being the most frequent
> one, so we should wait for his take...
As I mentioned before in the thread that started the discussion.
Pushing to master directly should only be done when there is an imminent 
problem that needs fixing right away. That is a very rare occasion. 
Everything else should be done using PRs and standard review.
As Andy remarked, small stuff can be merged by one self. Having a PR 
trail, even for the small things, is just good practice so everybody can 
see the same things unfold.

I don't care about branch protection as such. It is a corset to remove 
the blood flow to the impulsive parts of the brain. Usually I would 
prefer to kill my brain in other more pleasant ways. Technical measures 
never really fix bad habits and can cause collateral damage if not 
applied with great care. In the end, it is a balancing act.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] branch protection turned on

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

On September 17, 2026 9:14:42 PM GMT+08:00, andy pugh <bod...@gm...> wrote:
>On Thu, 17 Sept 2026 at 13:44, Luca Toniolo <lu...@ai...> wrote:
>
>> I ask because most of my direct pushes have been minor doc fixes and such, where a PR is mostly clicking through ceremony.
>
>Do you push directly to master? Or via a PR? It's perfectly possible
>to create a PR and then merge it yourself for trivial /
>uncontroversial changes.
>

Pushing directly to master It's not my usual or preferred workflow, but I did do it a couple of times, on locally tested uncontroversial changes I didn't want to wait the CI for. PR and self merge works well for me, I don't really have a dog in this fight... But I keep track of the commits, I think (but might be wrong) every active dev other than Bertho has pushed to master on a few occasions, Chris being the most frequent one, so we should wait for his take...

Re: [Emc-developers] branch protection turned on

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

On Thu, 17 Sept 2026 at 13:44, Luca Toniolo <lu...@ai...> wrote:

> I ask because most of my direct pushes have been minor doc fixes and such, where a PR is mostly clicking through ceremony.

Do you push directly to master? Or via a PR? It's perfectly possible
to create a PR and then merge it yourself for trivial /
uncontroversial changes.

Historically we had our own git server, and those devs that had access
pushed their changes directly. Those that did not have access would
have to email a patch to a core dev to be reviewed and (maybe) merged,
We then moved to GitHub and those same developers retained the ability
to push directly. This made things simpler and more transparent for
contributors without push access.

We haven't previously insisted on PRs, and I quite often push to wlo
without a PR.

I think it's probably better to go via a PR, mainly for consistency,
even if it is self-merged by the developer.

-- 
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] branch protection turned on

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

Rene,
Just to be clear on the record: I don't think anyone objects to the review process itself; I agree it's valuable, especially for the big changes that touch many things. But I think the question worth asking is a slightly different one: not "do we want reviews," but "do we want reviews enforced for everything, including trivial stuff?"
I ask because most of my direct pushes have been minor doc fixes and such, where a PR is mostly clicking through ceremony. And let's be honest, pushes to master have broken the tree for a few hours before; that happens, and we've always fixed it. I'm not sure that alone warrants locking down the whole workflow.
None of this is meant as a dig at turning protection on; I understand why you did it given this week's events, and reverting the mess was probably no fun. I'd just have preferred the question to go to the list before the switch flipped, since it changes how everyone works day to day.
Being the newest voice here I'm happy to go with whatever the group decides either way, but figured it was worth saying out loud.

Luca


On September 17, 2026 6:44:54 PM GMT+08:00, Rene Hopf via Emc-developers <emc...@li...> wrote:
>
>
>On 9/17/26 03:50, Chris Morley wrote:
>> When did we agree on that?
>
>It was already the case when I joined the project, and people have been doing this for years, except for minor bugfixes.
>It is also mentioned in the documentation. Does anyone object the idea of a review process?
>especially for large changes that touch many things, this is important.
>
>> If we did why did we not set protection on then?
>
>because nobody turned it on.
>
>> ________________________________
>> From: Rene Hopf via Emc-developers <emc...@li...>
>> Sent: September 16, 2026 11:56 PM
>> To: EMC developers <emc...@li...>
>> Cc: Rene Hopf <ren...@ma...>
>> Subject: [Emc-developers] branch protection turned on
>> 
>> Due to the recent events on github, I have turned on branch protection
>> on github. This means that everything that goes into master must go
>> through a PR, like we all have agreed to for a long time.
>> This gives other developers a chance to review and talk about your
>> changes. Now it is enforced by github. The changes have been reverted.
>> Same applies for 2.x branches.
>> 
>> René
>> 
>> 
>> _______________________________________________
>> 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] branch protection turned on

[Rene H. <ren...@ma...>]

On 9/17/26 03:50, Chris Morley wrote:
> When did we agree on that?

It was already the case when I joined the project, and people have been 
doing this for years, except for minor bugfixes.
It is also mentioned in the documentation. Does anyone object the idea 
of a review process?
especially for large changes that touch many things, this is important.

> If we did why did we not set protection on then?

because nobody turned it on.

> ________________________________
> From: Rene Hopf via Emc-developers <emc...@li...>
> Sent: September 16, 2026 11:56 PM
> To: EMC developers <emc...@li...>
> Cc: Rene Hopf <ren...@ma...>
> Subject: [Emc-developers] branch protection turned on
> 
> Due to the recent events on github, I have turned on branch protection
> on github. This means that everything that goes into master must go
> through a PR, like we all have agreed to for a long time.
> This gives other developers a chance to review and talk about your
> changes. Now it is enforced by github. The changes have been reverted.
> Same applies for 2.x branches.
> 
> René
> 
> 
> _______________________________________________
> 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] branch protection turned on

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

When did we agree on that?
If we did why did we not set protection on then?
________________________________
From: Rene Hopf via Emc-developers <emc...@li...>
Sent: September 16, 2026 11:56 PM
To: EMC developers <emc...@li...>
Cc: Rene Hopf <ren...@ma...>
Subject: [Emc-developers] branch protection turned on

Due to the recent events on github, I have turned on branch protection
on github. This means that everything that goes into master must go
through a PR, like we all have agreed to for a long time.
This gives other developers a chance to review and talk about your
changes. Now it is enforced by github. The changes have been reverted.
Same applies for 2.x branches.

René


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

Re: [Emc-developers] branch protection turned on

[Rene H. <ren...@ma...>]

On 9/17/26 02:42, Luca Toniolo wrote:
> Oops, turns out I don't have authorization to do that, so you'll have to 
> do it René
> Please toggle off the
> "Require branches to be up to date before merging"
> or explain why it should stay toggled on...

I have turned it off.

> 
> *Luca Toniolo*
> 
> On 9/17/2026 7:56 AM, Rene Hopf via Emc-developers wrote:
>> Due to the recent events on github, I have turned on branch protection 
>> on github. This means that everything that goes into master must go 
>> through a PR, like we all have agreed to for a long time.
>> This gives other developers a chance to review and talk about your 
>> changes. Now it is enforced by github. The changes have been reverted. 
>> Same applies for 2.x branches.
>>
>> René
>>
>>
>> _______________________________________________
>> 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] branch protection turned on

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

Oops, turns out I don't have authorization to do that, so you'll have to 
do it René
Please toggle off the
"Require branches to be up to date before merging"
or explain why it should stay toggled on...

*Luca Toniolo*

On 9/17/2026 7:56 AM, Rene Hopf via Emc-developers wrote:
> Due to the recent events on github, I have turned on branch protection 
> on github. This means that everything that goes into master must go 
> through a PR, like we all have agreed to for a long time.
> This gives other developers a chance to review and talk about your 
> changes. Now it is enforced by github. The changes have been reverted. 
> Same applies for 2.x branches.
>
> René
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] branch protection turned on

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

I rarely push to master (only minor doc fixes and changes to my own 
code, which no one would care anyhow) so the change does not effect me 
much, but I don't think
"Require branches to be up to date before merging"
option should be toggled, this just creates friction for no real 
benefit, I am going to turn that back off, I think you might have it on 
by mistake, if not I'd like an argument as to why it should be toggled...

*Luca Toniolo*


On 9/17/2026 7:56 AM, Rene Hopf via Emc-developers wrote:
> Due to the recent events on github, I have turned on branch protection 
> on github. This means that everything that goes into master must go 
> through a PR, like we all have agreed to for a long time.
> This gives other developers a chance to review and talk about your 
> changes. Now it is enforced by github. The changes have been reverted. 
> Same applies for 2.x branches.
>
> René
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] branch protection turned on

[Rene H. <ren...@ma...>]

Due to the recent events on github, I have turned on branch protection 
on github. This means that everything that goes into master must go 
through a PR, like we all have agreed to for a long time.
This gives other developers a chance to review and talk about your 
changes. Now it is enforced by github. The changes have been reverted. 
Same applies for 2.x branches.

René

[Emc-developers] Video Developer Meeting Sunday 2026-09-13 10:00 CEST

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

Hi,

It's been another two weeks and this is a reminder/invitation for our 
upcoming video meeting.

According to our bi-weekly schedule alternating between "early" and
"late", next video meeting is this Sunday at 10:00 CEST.


Agenda available online: 
https://github.com/LinuxCNC/linuxcnc/discussions/4497
Please comment there for anything you think should be on the agenda.


https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=9&day=13&hour=8&min=0&sec=0&p1=319&p2=236&p3=240&p4=136

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

[maurice e h. <ghe...@sh...>]

On 9/8/26 06:17, Bertho Stultiens wrote:
> On 9/8/26 11:03 AM, andy pugh wrote:
>> Is this discussion based on an expectation of withdrawing RTAI
>> support? My impression from scanning PRs has been that RTAPI support
>> has been expanding, with improved support for RTAI and also for
>> Xenomai.
> Retiring RTAI would be a LinuxCNC 3.0 thing. A lot of bitrotted code 
> has been fixed and Xenomai got fixed too. As long as the code is 
> there, it must be maintained.
>
> The driver problem is that some of these cards are ISA and I have a 
> hard time believing that anyone would buy a fortune swallowing modern 
> industrial PC to get an old card working with a /new/ LinuxCNC. Even 
> with the PCI cards you'd have a very hard case these days.
>
> If you use an old PC, then you may run into the problem of memory and 
> speed with any modern software. So you are still limited to older 
> versions/distros/kernels.
>
> Nobody would build a new system like that today. Only (desperate) 
> repairs of old systems that cannot be upgraded right away would ever 
> reuse the old stuff.
> If you ever upgrade these old systems, then you'd buy a newer more 
> capable PC/SBC and IO board with full support. And that would fill 
> less space and be cheaper to boot.

And, given the modern architectures of today, would draw far less 
power.   My arm64 (rpi4) and monitor that's nicely running my 11x56 
Sheldon, draws less than 40 watts when idle.  If changing the interface 
wasn't so costly, my triplet of old Dells drawing 300+ watts each would 
get rebuilt to be run by a pi clone.  One thing prevents that.

The heat helps heat the well insulated garage, which since all aux heat 
is electric, the net gain would be offset by the increased power drawn 
by the heaters.

Just to see if I could, I built a pi based backup that grabs the 
/usr/home/gene directory of 5 other machines using rsymc as the engine,  
With almost 12 TB of SSD raid 6 storage but not counting a small 
monitor, idle power draw is 14.5 watts, deep in a backup run it hits 
just under 20 watts.  And it is as fast as amanda ever was.

But now I'm approaching the far end of the bathtub curve.  I'm now 91 
with a birthday in October.

Cheers, Gene

Re: [Emc-developers] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

On Tue, 8 Sept 2026 at 11:49, Luca Toniolo <lu...@ai...> wrote:
>  that card gets
> ported (pluto first, it compiles on uspace today);

Pluto might already be something to deprecate. It needs a parallel
port that it works with. Which appears to be random and unpredictable.
Jeff was proposing its removal 13 years ago!

https://sourceforge.net/p/emc/mailman/message/31492674/

--
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] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

On 9/8/26 6:17 PM, Bertho Stultiens wrote:
> On 9/8/26 11:03 AM, andy pugh wrote:
>> Is this discussion based on an expectation of withdrawing RTAI
>> support? My impression from scanning PRs has been that RTAPI support
>> has been expanding, with improved support for RTAI and also for
>> Xenomai.
> Retiring RTAI would be a LinuxCNC 3.0 thing. A lot of bitrotted code 
> has been fixed and Xenomai got fixed too. As long as the code is 
> there, it must be maintained.
>
> The driver problem is that some of these cards are ISA and I have a 
> hard time believing that anyone would buy a fortune swallowing modern 
> industrial PC to get an old card working with a /new/ LinuxCNC. Even 
> with the PCI cards you'd have a very hard case these days.
>
> If you use an old PC, then you may run into the problem of memory and 
> speed with any modern software. So you are still limited to older 
> versions/distros/kernels.
>
> Nobody would build a new system like that today. Only (desperate) 
> repairs of old systems that cannot be upgraded right away would ever 
> reuse the old stuff.
> If you ever upgrade these old systems, then you'd buy a newer more 
> capable PC/SBC and IO board with full support. And that would fill 
> less space and be cheaper to boot.
>

Agreed: retiring RTAI is a 3.0 decision, and until then the code stays 
maintained.

On Andy's point about RTAPI support expanding: that expansion is real 
but it is uspace work. Xenomai (posix skin and EVL) lives entirely in 
uspace_xenomai*.cc, no kbuild pass, no kernel modules, and the kernel 
patch side is upstream's burden, not ours. RTAI kernel mode is the only 
path that requires kernel module builds and these ten drivers. 
Deprecating RTAI does not touch any of the growing parts.

So why not sequence it as: mark these drivers deprecated in the 2.10 
docs and release notes, removal slated for 3.0; if a user with upgrade 
intent appears for a specific card during the cycle, that card gets 
ported (pluto first, it compiles on uspace today); at 3.0 the drivers go 
with RTAI. The deprecation notice doubles as the poll, reaching more 
users than any single list post. Repairs of old systems stay on old 
distros, as you said, so master removal strands nobody.

The drivers could carry this deprecation independently of a project-wide 
RTAI decision. It is a docs-level change, and if RTAI survives into 3.0 
the list can be re-evaluated then.

Re: [Emc-developers] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

On 9/8/26 11:03 AM, andy pugh wrote:
> Is this discussion based on an expectation of withdrawing RTAI
> support? My impression from scanning PRs has been that RTAPI support
> has been expanding, with improved support for RTAI and also for
> Xenomai.
Retiring RTAI would be a LinuxCNC 3.0 thing. A lot of bitrotted code has 
been fixed and Xenomai got fixed too. As long as the code is there, it 
must be maintained.

The driver problem is that some of these cards are ISA and I have a hard 
time believing that anyone would buy a fortune swallowing modern 
industrial PC to get an old card working with a /new/ LinuxCNC. Even 
with the PCI cards you'd have a very hard case these days.

If you use an old PC, then you may run into the problem of memory and 
speed with any modern software. So you are still limited to older 
versions/distros/kernels.

Nobody would build a new system like that today. Only (desperate) 
repairs of old systems that cannot be upgraded right away would ever 
reuse the old stuff.
If you ever upgrade these old systems, then you'd buy a newer more 
capable PC/SBC and IO board with full support. And that would fill less 
space and be cheaper to boot.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

If motenec is developing an ethercat board, there is no need for their original driver when they have no stock. People will use the ethercat master to connect to their new devices.
 
Rod Webster  

 
On 2026-09-08 19:04, andy pugh  <bod...@gm...>  wrote:
> On Tue, 8 Sept 2026 at 06:01, Luca Toniolo  <lu...@ai...>  wrote:
>
> >  That leaves the direction question you didn't take a position on:
>
> I looked into the same question when I started my own (superseded)
> task to update the HAL pins to all be 64-bit. I concluded that there
> were likely to be very few of these boards out in the wild.
> I attempted to contact the vendors, to ask if they would be able to
> test, and only got a reply from Vital Systems, maker of the Motenc
> card. [1]
>
> They have no cards remaining to test with, and are not aware of any
> currently in use.
>
> I decided that I would update the drivers anyway.
>
> Is this discussion based on an expectation of withdrawing RTAI
> support? My impression from scanning PRs has been that RTAPI support
> has been expanding, with improved support for RTAI and also for
> Xenomai.
>
> [1] Motenc are developing an EtherCAT board aimed at LinuxCNC.
>
>
>
> --
> 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] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

On Tue, 8 Sept 2026 at 06:01, Luca Toniolo <lu...@ai...> wrote:

> That leaves the direction question you didn't take a position on:

I looked into the same question when I started my own (superseded)
task to update the HAL pins to all be 64-bit. I concluded that there
were likely to be very few of these boards out in the wild.
I attempted to contact the vendors, to ask if they would be able to
test, and only got a reply from Vital Systems, maker of the Motenc
card. [1]

They have no cards remaining to test with, and are not aware of any
currently in use.

I decided that I would update the drivers anyway.

Is this discussion based on an expectation of withdrawing RTAI
support? My impression from scanning PRs has been that RTAPI support
has been expanding, with improved support for RTAI and also for
Xenomai.

[1] Motenc are developing an EtherCAT board aimed at LinuxCNC.



--
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] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

I would deprecate them now.    From a user's perspective, there are just too many axis simulations, it becomes very confusing when looking to try a feature. Thats what I find anyway.
 
Rod Webster  

 
On 2026-09-08 14:59, Luca Toniolo  <lu...@ai...>  wrote:
> On 9/8/2026 12:01 AM, andy pugh wrote:
> >  I think that most of these would actually build with preempt-rt, but
> >  are not built as they can't be tested.
> >  (Ie, I think that it is a testing problem, not a building problem,
> >  that has them omitted from the uspace builds)
>
> I tested that assumption: with uspace flags, none of the seven C drivers compile as they stand:
>
> - hal_stg, pci_8255, hal_ax5214h, hal_vti: asm/io.h, no userspace equivalent
>
> - hal_motenc, opto_ac5: pci_get_device, ioremap_nocache, raw  <linux/pci.h>
>
> - hal_evoreg: closest, uses rtapi_io.h, but still calls ioremap/writew directly
>
> - pcl720.comp: asm/io.h plus kernel types
>
> Only pluto_servo/pluto_step compile today (userspace sys/io.h path since 2007)
>
> So it is a build problem too, not only testing. The porting path exists
> (rtapi_pci.h/rtapi_io.h shims, hm2_pci and hal_gm show how), but each
> driver needs real work plus hardware to validate.
>
> That leaves the direction question you didn't take a position on:
>
> A. Port and keep maintained, on the assumption users exist but haven't
> shown up yet. Cost: porting effort per driver, review bandwidth, and
> code that ships untested anyway until a tester appears.
>
> B. Deprecate now, bring back on request. Add the deprecation note,
> announce on forum + mailing list, remove after one cycle. If a real user
>   appears later for a specific card, the git history keeps the driver and
>   porting it then is the same effort as porting it now, except then we
> have a tester from day one.
>
> I favor B. Shipping freshly ported drivers with zero hardware validation
>   is the same untested state we have today, just with more code to
> maintain. Do you see a concrete reason to prefer A for any specific
> card?PS: Forum poll result: a pci_8255 user reported in on the forum. He is
> running a 3.x RTAI kernel, so likely an old LinuxCNC release that will
> keep working regardless of what master does. Unknown yet whether he
> upgrades or would test a uspace port; forum went down before I could
> follow up. Will update when I can reach him.
>
> This is the distinction the poll needs to draw: "card still in service"
> vs "card owner plans to upgrade past the removal". Only the second
> argues for keeping or porting.
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

On 9/8/2026 12:01 AM, andy pugh wrote:
> I think that most of these would actually build with preempt-rt, but
> are not built as they can't be tested.
> (Ie, I think that it is a testing problem, not a building problem,
> that has them omitted from the uspace builds)

I tested that assumption: with uspace flags, none of the seven C drivers compile as they stand:

- hal_stg, pci_8255, hal_ax5214h, hal_vti: asm/io.h, no userspace equivalent

- hal_motenc, opto_ac5: pci_get_device, ioremap_nocache, raw <linux/pci.h>

- hal_evoreg: closest, uses rtapi_io.h, but still calls ioremap/writew directly

- pcl720.comp: asm/io.h plus kernel types

Only pluto_servo/pluto_step compile today (userspace sys/io.h path since 2007)

So it is a build problem too, not only testing. The porting path exists
(rtapi_pci.h/rtapi_io.h shims, hm2_pci and hal_gm show how), but each
driver needs real work plus hardware to validate.

That leaves the direction question you didn't take a position on:

A. Port and keep maintained, on the assumption users exist but haven't
shown up yet. Cost: porting effort per driver, review bandwidth, and
code that ships untested anyway until a tester appears.

B. Deprecate now, bring back on request. Add the deprecation note,
announce on forum + mailing list, remove after one cycle. If a real user
  appears later for a specific card, the git history keeps the driver and
  porting it then is the same effort as porting it now, except then we
have a tester from day one.

I favor B. Shipping freshly ported drivers with zero hardware validation
  is the same untested state we have today, just with more code to
maintain. Do you see a concrete reason to prefer A for any specific
card?PS: Forum poll result: a pci_8255 user reported in on the forum. He is
running a 3.x RTAI kernel, so likely an old LinuxCNC release that will
keep working regardless of what master does. Unknown yet whether he
upgrades or would test a uspace port; forum went down before I could
follow up. Will update when I can reach him.

This is the distinction the poll needs to draw: "card still in service"
vs "card owner plans to upgrade past the removal". Only the second
argues for keeping or porting.

Re: [Emc-developers] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

On Mon, 7 Sept 2026 at 12:27, Luca Toniolo <lu...@ai...> wrote:

> We would like to find out who still depends on the drivers that only
> build for RTAI kernels. These are all legacy ISA/PCI/parallel-port cards
> from the early 2000s:
>
> - Servo-to-Go (hal_stg)
> - Motenc (hal_motenc)
> - Vigilant VTI (hal_vti)
> - Siemens EVOREG (hal_evoreg)
> - Axiom AX5214H (hal_ax5214h)
> - Opto22 AC5 (opto_ac5)
> - pci_8255
> - Advantech PCL720 (pcl720)
> - Pluto-P FPGA servo/stepper (pluto_servo, pluto_step)

I think that most of these would actually build with preempt-rt, but
are not built as they can't be tested.
(Ie, I think that it is a testing problem, not a building problem,
that has them omitted from the uspace builds)

-- 
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] Still using RTAI-only hardware drivers? (STG, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P)

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

Hi all,

We would like to find out who still depends on the drivers that only 
build for RTAI kernels. These are all legacy ISA/PCI/parallel-port cards 
from the early 2000s:

- Servo-to-Go (hal_stg)
- Motenc (hal_motenc)
- Vigilant VTI (hal_vti)
- Siemens EVOREG (hal_evoreg)
- Axiom AX5214H (hal_ax5214h)
- Opto22 AC5 (opto_ac5)
- pci_8255
- Advantech PCL720 (pcl720)
- Pluto-P FPGA servo/stepper (pluto_servo, pluto_step)

If you run any of these on an RTAI build of LinuxCNC, please reply and 
say which one.

Note: the Pluto-P drivers could be made to work on normal preempt-rt 
(uspace) builds with modest effort, so if you have Pluto-P hardware and 
would test it, definitely speak up.

Background: https://github.com/LinuxCNC/linuxcnc/issues/4505

Re: [Emc-developers] Canceled: Video Developer Meeting Sunday 2026-08-30 20:00 CEST

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

The video meeting has been canceled because the bbb server is under 
maintenence. It is unclear when it will be online again. Probably not in 
time today.


On 8/28/26 3:19 PM, Bertho Stultiens wrote:
> Hi,
> 
> It's been another two weeks and this is a reminder/invitation.
> 
> Agenda: https://github.com/LinuxCNC/linuxcnc/discussions/4389
> 
> According to our bi-weekly schedule alternating between "early" and 
> "late", this video meeting is this Sunday 2026-Aug-30 at 20:00 CEST.
> 
> https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
> Access code: 869782
> 
> https://www.timeanddate.com/worldclock/meetingdetails.html? 
> year=2026&month=8&day=30&hour=18&min=0&sec=0&p1=319&p2=236&p3=240&p4=136



-- 
Greetings Bertho

(disclaimers are disclaimed)