Advanced Search

It should work indeed when selected fully preempted. At least it worked for me until 6.11 (after patching). What's strange for me is that when it's set manually to rt prio it works

Start with
DIRSETUP = 20000
DIRHOLD = 20000
STEPLEN = 5000
STEPSPACE = 5000
And if it works, change only last two to 4000, test, 3000 etc, until you notice missed steps, then add 50% more to that, i would add 100% just to be safe.

Is the tittle OK now?

www.phoronix.com/news/Linux-6.12-Does-Real-Time
6.12 does not need patching for AMD64 according to the above, it should work with just setting the preemption to full. That needs to be tested.
The list of all architectures that have ready made debs for 6.12 RT.
packages.debian.org/search?keywords=linux-image-rt
And yes, i know patching sometimes does not work as it should, but can not recall what would cause that as last i did patching was when Linux Mint 17.n came out.
And yes, we do need evidence of it not working on AMD64 or X86_64 (there are no new kernels for X86 for quite some time).

Anyway thanks for the link, just tried the kernel from the link and that one works correctly indeed. Still a mystery for me while mine doesn't get detected, because rhey're compiled with fully preemptible (realtime) in menuconfig.

Why compiling myself? Because I use it on a pc with Fedora and an Orange Pi 5. I'll dig further into it.

If i have a maximum frequency of 500k(pps) and a minimum pulse width of 1us how do i convert those numbers into the step and direction timings of a joint that i put into my ini file?

In the other terminal you can read "PREEMPT_,RT".

In the screenshot of the whole screen (where I put the rtapi processes manually on the FIFO scheduler with rt priority) you can see from the result that it's definitely a realtime kernel, but somehow just not detected correctly since 6.12.
Do I really need to send a proof that it's the same with x86?

It's a bit annoying that the title got changed to something that attracts less attention, while it's not even limited to only that device/architecture.

Since you didn't reply on it but you did reply on other topics in this section I assumed that you didn't read it. So by trying to prevent of getting a lot of noise in this topic (didn't work) I pushed the report button.

OP-

First thing to do is run LCNC from the command line, and turn on some level of debugging in the INI file.  That's helped me catch 'backstage' problems, or at least I can figure out where to start looking.

Then run LCNC - with and without twopass - and see what is happening in the terminal window.

I suggest changing the terminal preferences to 'unlimited scroll-back' before you start.

Once you capture a problem ion the terminal, take a screenshot and post it up here.

Nothing on the screenshots says it is a fully preemptible kernel in use, and it is also noted by LinuxCNC in the terminal saying "using posix non-realtime".
Why the report? You already said that here and it was not changed (the tittle) as there is no evidence the normal AMD64 kernel also does the same thing, both screenshots contain only Orange PI.
Instead, try patching the kernel again and choosing fully preemptible in menuconfig (was it called that?) ... but then again, why patching, there are ready made debs for AMD64 with RT patching already done, no idea if there is one for OPI though.
AMD64:
packages.debian.org/experimental/amd64/l...c6-rt-amd64/download
Nothing for AARCH64 though.

It is not an error as noted on the warning, well not always, so you do need to test on a machine or use a DVM to check the output pins on the parallel port connector.

You are correct.  I forgot to sudo the first time.
I did try to run LinuxCNC with the new address.
I got the same error with the new address.
The demo runs.  Computer is not connected to the mill so I don't know if signals are going to the port.
Thanks for your assistance.