Advanced Search

A couple of things related to choosing a Kernel for Linuxcnc.

For the RPi4 you require options for the bcm2711 in the config.
For the RPi5 you require options for the bcm2712 in the config.

The change of the SoC broke a lot of stuff that broke GPIO stuff. What previously worked on the RPi4 failed on the RPi5. In the context of Linuxcnc this required a rewrite of the SPI driver for the RPi5.

For both SoCsmust be set. Otherwise we dont get the real time model required.

In the link you gave for the configs only the bcm_2711 rt config has that option set. The bcm_2712 config does not.

With regards to the kernel version the one on the image is uname -a
Linux raspberrypi 6.12.11 #1 SMP PREEMPT_RT Mon Jan 27 00:10:15 AEDT 2025 aarch64 GNU/Linux

This was built from the 6.12.y branch in January. Whilst not to up to date 6 months later it was in January and has proved to be stable. With regards to the kernel itself there have been no reports of crashing, except one user whilst using GMOCCAPY but this was traced to zram swap issue.

This is the one running my RPi5 on the mill, it's been up for 39 odd days with no issues. Having the power saving stuff turned off on the wifi has been constantly connected for those 39 days. Usually it powers down after some time.

unknown wrote:

I've tried looking for a RT_PREEMPT kernel in the repos, but could only find kernels that were configured for Real time not Preemptive real time (which is what Linuxcnc requires).

the packages are on archive.raspberrypi.org . you want linux-image-6.12.34+rpt-rpi-v8-rt, it works for both RPi 4 and 5. there's a meta package linux-image-rpi-v8-rt that depends on the latest version of the RT kernel, but it gives you auto-updates with apt, which is not necessarily a good idea (e.g. the currently-latest 6.12.47 is hanging my Pi5 sometimes).

it is a proper PREEMPT_RT kernel:

in order for bootloader to use it, you need to add kernel=kernel8_rt.img to /boot/firmware/config.txt.

the kernel configs themselves are here .

@f355

I've tried looking for a RT_PREEMPT kernel in the repos, but could only find kernels that were configured for Real time not Preemptive real time (which is what Linuxcnc requires).
Debian doesn't have any support for the RPi5 as it doesn't have enough upstream kernel support.
wiki.debian.org/RaspberryPiImages#Overview

and

raspi.debian.net/tested-images/

So to get a full RT_PREEMPT kernel the only solution it would seem is to roll our own. Which would not be a suitable solution for upgrading.

One solution maybe if Linuxcnc could host suitable kernels, but I really don't see the sense in a regular upgrade regarding the kernel in this situation. I'm still running the original kernel that was built whilst building the image in Jan 2025.

BTW running pi-gen builds a couple of flavours of images everything from lite to a fully image. Tho it does use a significant amount of disk space.

first of all, thanks for the kind(-ish, lol) words, I'm happy to be helpful to the community even if it is just planting ideas into smart people's minds

have you seen github.com/raspberrypi/rpi-image-gen? to me it looks like a better fit for the purpose - all we need is to install some packages and configure some things, right? building the entire distro from scratch seems excessive.

Hi,
i wrote a hal component in python to control some I2C devices

*  pcf8574 : Digital IO's
#  ads1115 : Analog input
#  lm75  : temperature sensor
#  hd44780 : LCD display

It is actually part of the RIO project, but can also run independently.
Maybe someone can use it.
It's also no problem to install additional devices. Just let me know what you need; I have almost everything here


Cheers Olli

Link: github.com/multigcs/riocore/blob/dev/rio...ins/rpii2c/rpii2c.py

After a bit of a discussion with forum member f355 it came to my attention that an image based on the "Raspiberry Pi Way" maybe possible. Whilst a little "terse" at first he did raise some valid point and gave me time to reconsider some things. And eat some humble pie. I would like to give thanks for this...sometimes it's needed to find a new direction.

One reason for this idea is to make using the image more familiar to those used to the RPi ecosystem. Being able to use the RPi imager and setup some defaults may be beneficial as well.

At the moment I'm experimenting with pi-gen ( github.com/RPi-Distro/pi-gen/tree/bookworm-arm64 ) target a bookworm based image, as I feel as time moves on and more familiarity is gained using the tool a working image with a RT kernel and Linuxcnc will be produced and can be compared to the existing image. Wifi seemed to be a bit of a issue from time to time.

Hopefully from this in the readme "Tool used to create Raspberry Pi OS images, and custom images based on Raspberry Pi OS, which was in turn derived from the Raspbian project." distribution should not be an issue.

So the first task is to create a basic image to get a feel for the tool.

All input whether positive or negative ( remember coming from Australia I'm somewhat hard to offend ) is welcomed and encouraged. Rather than the way it has happened in the past I would like this to be more of a community effort with regards to packages. Please remember the object is not to create a daily driver OS but one that makes the entry easier to running Linuxcnc on a Pi. Whilst it may be beneficial to include CAD\CAM I feel leaving this out will create a smaller image to download, and as there are many packages available half will be happy, half wont be and the other half may not have a preference.

As a final note the final decision will have to be made by the Linuxcnc hierarchy as I dont want to go against their wishes, but for the moment I think at least a discussion is good idea, and see what the community thinks.

Yes,yes I know some our esteemed members aren't exactly keen (not recommend) on the RPi due to cost factor.

Cheers
Rob

Here comes the "Grumpy Old Man Response".

1: That's your method. I was held back from including gnome network manager, a situation that didn't sit well with myself. Which is great as the user can have the option of enabling and disabling wifi as required. Adding this will be an improvement (as will the turnng off of the power saving features of the wifi, something I haven't recommended as thb I could see it being more hassle that it's worth to describe what is required, delving into systemd is required). Tho I did manage to sneak in gvfs-backends & gvfs-fuse. The zram swap thing was a bit of a debacle, something I blame myself for not fully checking the swap, which did rear it's head. Yes I get the ID Ten Tea award for that.
2: No patch was required for RT_PREEMPT, that was part of the Vanilla Kernel that was selected (which required thought put into it) and many thanks to a certain member that helped clarify a few things regarding that, any patches applied were those that the RPi Foundation has on their github, no trickery on our side. Until their particular patches make it to the mainline kernel they will always be applied.
3: You could of asked. Now this is really the bit I thought was a terrible assumption to make.You think those that manage Linuxcnc allow randoms to upload untested content to their server ? That is something extremely silly to assume, especially with 20 years of Linux experience.
4: Up to you.
5: That's people assuming things regarding the menu config. It has been clearly stated that whilst the image runs on the RPi and the kernel has been sourced via the RPi Foundation, it is Debian at is core and not RPi OS. Someone who thinks critically would assume that there would be differences in how things are done. Not understanding, excepting or realising that that things will always be the same way on a particular platform is rather naive (I would say silly myself).Apart from the kernel and a couple of RPi specific utilities, Debian was the easier solution. Basing anything on RPiOS requires removing a lot of Raspberry Pi Foundation branding from any image that was built and distributed. Hence the reason there was a switch from using Ubuntu in the emc2 days to Debian now.

Being able to actually install Linuxcnc & a required kernel onto a Raspi OS image would have been infinitely simpler, but the copyrighted branding becomes an issue. Which is their right and a good thing as well as it a protection for users, as a lot of people will blindly down load this or that. Hence scammers have it easy.
Supplying instructions for getting Linuxcnc on a Raspi image may have been one way, but people being what people are. I used to be a traffic controller and have lost confidence in people being able to follow instructions or wanting to.

Ah, I did not realize the images were yours, I thought it was the great cornholio dude (is that your old account, maybe?) and rodw who worked on them for some reason. That explains your interest in my setup, cool, I can certainly give you some feedback on why I chose RPi OS.

1. as mentioned before, I can't connect to wi-fi without running menu-config, and to run it, I need either a console or Ethernet. Connecting either is a hassle for me, I tend to run my Pi's headless with TigerVNC/noVNC. I've briefly looked at the rpi-image-builder the images are based upon and it seems like it's possible to mount the boot partition and edit some text file there so it sets stuff up on the first boot, but I have not dug deep - with RPi OS I can set that up in RPi Imager, together with the ssh key, the username and other stuff, it's much easier and it just works.

2. The kernel is custom-built from source with an RT patch, which makes it tricky to update it if I ever need to. There are now official RT kernels in the RPi apt repo and I can just apt install the new kernel. In general, the update cadence/mechanisms for the entire thing were - and still are - unclear to me.

3. I couldn't find the git repo where these images are built from. github.com/LinuxCNC/rpi-img-builder-lcnc is 2 years old, rodw's upstream is slightly newer but still older than the published images. It seemed like those images were built ad-hoc once by someone and just uploaded to the server, and that looked like a bit of a red flag to me.

4. cnc/cnc as default username/password is not something I want. I could create a user for myself, sure, but with RPi Imager I don't have to, so why bother.

5. this entire menu-config thing is not what RPi OS uses and what people - myself included - are familiar with. Not a big deal of course, but in general - Raspberry Pi has an official distro that is well-maintained and well-known, and I don't see why I, for one, should use something else in the second half of 2025. I understand why your images were built in the first place - PREEMPT_RT was not mainline at the time, RPi OS tended to push Wayland aggressively, you wanted a turn-key solution that less experienced people could just write to an SD card and use, my headless requirement is rather uncommon, etc., etc., but my personal preferences kicked in and I made a choice.

I hope that clarifies it!

I'm sorry, what am I supposed to find in that thread? I don't have any questions about the LinuxCNC-provided image and never had. I came here to report a broken dependency in the apt repo, not to ask how to run LinuxCNC on an RPI.

Just to be clear, I have seen that thread, it is kinda hard to miss, and I've played with the image. For my personal preferences, I've decided to go with Raspberry Pi OS instead and I'm totally happy with it. What are we even discussing at this point?

I'm sorry if that came out sounding arrogant, that was not the intent. I totally understand why Tommy suggested apt update, I just wanted to quite literally save his and my time.

I can certainly build it myself, or use 2.9.4 that works just fine for my purposes, or whatever. I don't have a problem, LinuxCNC has a problem, and being unable to fix it for everybody, I'm reporting it here in hopes that someone blessed with permissions does that.

Raspberry Pi OS Lite doesn't come with a desktop environment or a window server pre-installed, so I'm free to choose what to use (XFCE obviously lol). PREEMPT_RT kernel is available as an official package from Raspberry Pi debian repos these days and works fine. I'm not sure what the "official" linuxcnc raspberry pi image would give me at this point, and it is much harder to use for me personally - it requires me to connect a display/keyboard, for example. As to libgpiod or axis, I don't use either so I can't say anything about them.

With your 20 years experience if you really want 2.9.5 on arm you can always build it yourself.
As for the version differences that will depend on the system the packages were built on.
Was there any reason, apart from the official arm image being based on Bookworm, that you went with Raspberry Pi OS Lite ?
Does that give you the choice of Wayland or X11.
Look we get a lot of users with varying degrees of Linux Experience, as we can't tell your experience usually we start advice with the basics. So no it's not a waste of time starting with said basics.
From memory when I attempted to build an RPi image based on Devuan, based on Trixie or maybe unstable, there was an issue with the libgpiod library. At the time the libgpiod driver would not compile against version 2.0 so I abandoned that idea due to that. As far as I know I'm unaware of that situation has changed. Bear in mind that there are some issues that affect Axis in 2.9.5 and 2.9.6 that have been well reported on the forum. It would appear they have been resolved but looks like we need to wait for a 2.9.7 version.

Thank you for fixing this, Andy, the new key works just fine!

However, the debian package itself seems to have a broken python3 dependency. I'm on the latest Raspberry Pi OS Lite (which is basically trixie with a custom kernel and a few Pi-specific tools installed). Any particular reason for the arm64 package to want python3 < 3.12? amd64 one depends on 3.13, and so does linuxcnc-uspace 2.9.4 that comes with trixie.

D'oh

really got to stop trying to use forum on my phone.

Habe ich das mit der Konfig der mesa Karten richtig verstanden, dass ich zuerst herausfinden muss wieviele Ein- und Ausgänge ich brauche um dann die passende Konfig auf die Karte zu spielen?

Installiere linuxcnc auf den Raspberry und starte einfach pncconf, dann kannst du dir die Mesakarte aussuchen und siehst selber was man braucht.
Du brauchst die Steigung deiner Spindeln (der Hersteller gibt 0.00375mm/schritt an, also vermutlich 1.5 oder 3 mm).
In pncconf werden Takt/Richtung für die Achsen fix vergeben sein, du musst den Pins nur korrekte Achsen zuordnen. Dann noch angeben an welchen Pins welche Endschalter hängen und das war eigentlich schon alles. Also praktisch nur von deiner HAL-Datei abschreiben.
Oder du schaust hier:  linuxcnc.org/docs/html/config/pncconf.html

Gartenzwerg wrote:

Was braucht so eine Karte an Stromversorgung? Die 24V werden doch nur benötigt wenn die Stepper (+Treiber) da direkt
draufhängen, oder?
 

5V. Die Treiber haben eine eigene getrennte Versorgung, die du ja schon hast. Wenn die Maschine per DB25 Kabel am Parallelport betrieben wurde, hat deine Maschine auch ein BOB, um den Parallelport zu schützen.
Das gezeigte BOB aus China ist nicht nur völlig nutzlos und überflüssig, sondern würde bei Direktverbindung die GPIO-Pins des Raspberrys ausknipsen, da die nicht 5V-tolerant sind. Das "Parallel Hat" von byte2bot hat deswegen vier Pegelwandler von 3.3V auf 5V und umgekehrt verbaut. Wenn man auf die verzichtet und die Maschine direkt am Raspberry betreibt, muss man die Eingangssignale auf 3.3V bringen.
Weiters muss man die Eingangspins gegen negative Spannungen schützen, indem man zumindest jeweils einen Vorwiderstand in Serie schaltet, am Besten in Verbindung mit einer Schottky-Diode mit möglichst kleinem Spannungsabfall (1N5817 oder so). Die Raspberry GPIO-Pins haben integrierte Schutzdioden, die laut meiner kurzer Recherche nur 1mA vertragen.

Die Chinesen scheinen bei deren Karten den falschen Busschalter verbaut zu haben: CBT16211A statt CBT16211. Laut Datenblatt ist das ein reiner Schalter ohne Pegelwandelfunktion, müsste also entweder gegen welche ohne A getauscht werden, oder die Pins dürfen nicht mehr als 3.3V sehen. Die chinesische 7I92 hat Vorwiderstände an den Pins, vermutlich weil den Chinesen beim ersten Test die FPGA-Pins wegen zu hoher Eingangsspannung gestorben sind. Falls die Widerstände 220Ohm haben, weiß ich woher sie die Idee haben 
Die Widerstände werden aber vermutlich zu klein sein, um die Maschine da einfach direkt anzuschließen.

Die Mesakarten laufen über TCP/IP. Die Adressen sollten fix sein. Man kann die Adresse der Karte per Jumper von 10.10.10.10 auf 192.168.1.121 oder so umschalten können. 

Da deine Maschine noch läuft, musst du die Pinbelegung eh im Computer haben. Ansonsten im Schaltplan oder in der Gebrauchsanweisung nachzulesen. Falls die nicht mehr vorhanden sind, einfach an den Kundendienst wenden. 
Wir können aber auch im Forum demokratisch abstimmen welche Pinbelegung deine Maschine hat.