Xenomai RT kernel

Hello,

is there any gentelman which has running Xenomai or Cobalt kernel for his iron?

I need some inspiration or talk what, how, prons and cons ... experiences !

thanks 

Thanks I did it with help of AI ... It was worse then Preemt-rt in default non custom stuff ... I left this idea when I saw how much custom thing I need to code alone to run something and it saves be 3us ...

great idea but much stuff around it

Hi
Meanwhile, there is Xenomai3 and Xenomai4 support in master branch.

Details:
github.com/LinuxCNC/linuxcnc/issues/3878

Prebuilt Kernels and Linuxcnc 2.9.10 back-port for Xenomai4:
github.com/hdiethelm/xenomai3-linuxcnc
github.com/hdiethelm/xenomai4-linuxcnc

For me, it works well and I fully switched to Xenomai4.

Thanks for the pointers, and for the prebuilt packages. They make it much easier for others to try this.

For context, here is where I ended up and why.

Hardware and goal
- Beckhoff C6930 industrial PC (i5-7500, 4 cores, no HT), Debian 12, no Beckhoff software.
- LinuxCNC with the IgH EtherCAT master, using an AX5203 drive over SoE.
- Strict 250 µs cycle, plus a custom 5-axis TCP (G43.4/G43.5) and a modified trajectory planner.

What I tried
1. Xenomai 3.3.3 Cobalt on Dovetail (CIP 6.1.170 kernel), built from source with Skylake tuning:
   - Core isolation, no P-states or C-states, tsc=nowatchdog, an i915 workaround and pci=noaer for the PLX backplane switch.
   - The native latency test showed about 3.6 µs max idle and 2.8 µs under load, with 0 overruns.
2. LinuxCNC on that kernel. At the time I was on 2.9 without a Cobalt flavour. Its HAL threads fell back to plain SCHED_FIFO in the Linux root domain, and latency-histogram showed about 36 µs, worse than PREEMPT_RT.
3. Xenomai 4 / EVL, with AI help, using default settings. In my hands it came out worse than PREEMPT_RT.

What I chose
Stock PREEMPT_RT (6.1.0-41-rt-amd64) with core isolation. On the isolated core at 250 µs, cyclictest gave 6–7 µs max, idle and under load. EtherCAT ran for a 30-minute soak with desktop load and stayed stable.

Xenomai's best case saved me about 3 µs, which is irrelevant against a 250 µs budget. To get even that, I would have had to write and maintain a lot of custom code myself: the glue between LinuxCNC, the EtherCAT master and the co-kernel, RTDM-capable NIC drivers, and the tuning for each. I decided that wasn't worth the maintenance, so I stayed on PREEMPT_RT.

What I'd like from this setup
- A hard 250 µs loop with low jitter that I can maintain on a stock Debian kernel.
- No dependence on a patched co-kernel for every kernel update.
- Eventually a self-contained appliance, with safety handled by external TwinSAFE/STO hardware.

Why I'm posting
- It's a great project, and I'm glad it works well for you.
- For anyone with a similar setup, the overhead around the co-kernel is real. On this hardware it buys microseconds, not a different class of determinism.
- If you have a minimal EtherCAT-master-on-EVL setup, or numbers for igb or e1000e with EtherCAT cycles, I'd like to compare. I'll also look at the Xenomai 3 / 4 support in master (issue #3878) with a fresh install.

Regards