What would be really useful (including to me) would be a flowchart that tracks a simple G-code command (like coolant-flood) from the Interpreter to the HAL pin.
There are so many layers and abstractions (not all of which seem necessary)
Oh, and a clear indication where the switch to realtime happens in this flow would be helpful too.

Yes, the biggest hurdle when working on an issue is figuring out which parts of the source code are involved in the first place. I have used Sourcetrail and Doxigen but what I really lack is a bigger picture.
- what happens in case of a program abort
- what is involved when the feed override value changes
....
That probably is the greatest loss when a long term contributor retires from the project.
Documentation of such trans code 'paths' would also likely be less prone to become outdated as the source code evolves.

MTTI wrote:

I’m not a programmer (only a bit of Python, and some BASIC and C). It took me the whole day to find this issue, moving a debug print line around the code to locate where it was getting stuck.Thank you for the explanations, and also for pointing out the second copy/paste bug, I’ve fixed that one on my side as well.

Now I need to follow up with Pronest, as the post-processor still doesn’t insert commas between the parameters...

Regards

Me either to be honest. I do this because it differs from my day job, gives me something new to continually learn, and because I enjoy it.

I appreciate your collaboration!

Is the grayscale encoder aligned to the carousel (ie, it corresponds 1:1 with the tool pockets) or is this an encoder on the motor?

The "gray" mode of the carousel comp is intended for the former case.

If it's a motor-mounted encoder look at using "counts" mode. (with an encoder counter that is scaled to the pocket spacing)

Segfaults are typically problems with the linuxCNC software writing out-of-bounds.
Are you running any custom HAL modules?
Which HAL components are in-use?

Sorry, but RTAI support has been a bit lax lately, though I am still committed to it at least in 2.9.

What would be really useful (including to me) would be a flowchart that tracks a simple G-code command (like coolant-flood) from the Interpreter to the HAL pin.
There are so many layers and abstractions (not all of which seem necessary)
Oh, and a clear indication where the switch to realtime happens in this flow would be helpful too.

I don't know why 2.9.3 was removed either,[1] but 2.9.7 should be better. (basically just the same, but with bugfixes)
And if you have previously down;oaded the 2.9.3 image, don't you still have it somewhere?

[1] And it's almost certainly me who did it

If you need an RTAI version of 2.9.7 I will try to build one.

But given your reported issues elsewhere it might be worth setting-up to build from source. It's not especially difficult, though there is a oe-time investment in installing all the build dependencies.

Get the basic tools:
Then get the LinuxCNC source code:
Then enter the source directory and switch to the 2.9 branch
Now you are going to need a whole bunch of packages, dpkg knows what you need: (you need to be in the linuxcnc-dev folder , where you can see the debian folder)
The only complication here is that the build will be a run-in-place (can exist alongside a standard install) and to chose it you need to run a script. (Yes, it really is dot-space at the beginning)

FwIw I have succesfully used a Macbook Air (with Linux installed) and a thunderbolt-to-ethernet adaptor to control a Mesa 7i96.

It is Linux so do not worry to much about security, and if you are worried yank out the internet cable.
Normally, if you do not click on some malware links in the browser or open e-mails containing malware, there is nothing to worry about, there are plenty of servers on public IP's that were never upgraded still working running Linux happily.
In short, if the machine works properly = never upgrade.
Long version:
I am fully aware of the psychosis caused by Microshaft spending billions on marketing to prove Linux is not secure, and they miserably failed as all Microsoft servers run Linux.
Windows will be someone else's property in 2 minutes flat if left on public IP.
The extremely bad thing is, that sentiment keeps getting perpetuated by lazy youtubers that play experts on youtube yapping about security being the same on both, it is NOT the same in any way, shape or form, and the worst thing is they talk about browser security that is close enough security vise but still not the same, while utterly ignoring the operating system security that is non existent on windows and extremely good on Linux.

You probably don't need ladder logic. I would think that it is do-able with HAL components. Maybe latch-on the spindle-enable when spindle commanded-speed is zero until measured spindle-speed is very, very near zero.

Maybe linuxcnc.org/docs/stable/html/man/man9/flipflop.9.html

I would need to experiment, but I am thinking setting "in" permanently to "true", clck being triggered by spindle-on ans reset triggered by spindle-off AND speed ~= 0.
(Spindle-off would be inverted spindle-on, and stopped status would use wcomp. )