Advanced Search

7I96S        DRIVE CN3

ENCA+          9
ENCA-         18
ENCB+        17
ENCB-           8
IDX+             7
IDX-            16

STEP+         2
STEP-         11
DIR+           4
DIR -          13

GND          12   (encoder ground= 7I96 TB2 pin 9 )
 

I see where you're coming from. I very much don't agree with it, but that's just me.

I compiled my first kernel for RedHat 7 in 2001 I think. had no idea what I'm doing but since then, the novelty of compiling kernels - or anything, really - has worn down, mildly speaking. I'm a software engineer by trade, very lazy at that, and I prefer to a) update things as soon as possible, because the more versions I skip, the harder the update would be, and b) don't do work if I can avoid it - don't write code if I can use a library, don't compile my own kernel if a pre-built one is available, don't configure things that I don't need configured, etc., because if I do that, it means I now own that thing, and if there is an issue with it, it is my responsibility if not to fix it, then to at least investigate if the issue was caused by my changes.

I guess we have differing world views, and that's perfectly alright!

Config attached.

One of my previous posts as a zip archive of the rpi-image builder used to build the RPi5 & RPi4 images.

I'm of the opinion of keeping the kernel locked is not such a bad idea. It prevents users from messing things up.
It can also save "I've updated my kernel and I have xxyyzz issues" and sometimes trying to help some people out is like pulling teeth. Sometimes you have to ask for the same information a couple of times because for whatever reason they don't think it's relevant. And sometimes Linuxcnc is a users first venture in Linux, after maybe using Mach or grbl. There's no reason why an experienced user can't use alternative kernels if required or wanted.
And TBH I don't think kernel building is such a large task. The first one I built was around the time of Redhat 6.0 on a 486 with 32MB RAM (Maybe around '99 or something like that). Yes it was a very, very slow task. Back in the day were one had to hand edit files to get a dial up connection.

As for updates.....there's some user's that have machines running on Ubuntu based versions of emc2. Bit like the ecu of a car\truck\snow mobile\jetski\road bike\off road bike or similar, not often an owner will think of updates if any are available.

unknown wrote:

Could you point me to any papers, references or any such peer reviewed articles explaining why the 16k page kernel is broken by design.

yeah no, sorry, I have used too strong wording there - 16k pages used to cause compatibility issues with older software, but I believe that has been a non-issue for several years now.

unknown wrote:

Ok you're telling me not to use a kernel that I have practical experience and have not had a single crash or anything similar.

not really, because I - still - have not seen the exact kernel configs that you've used in your images. are they on github somewhere?

all I'm saying is that the ONLY difference between bcm2711 and bcm2712 configs is that the latter enables 16k pages. we don't need them, the performance increase is practically zero for our application - LinuxCNC does not allocate huge amounts of memory in runtime. 4k pages work just fine and have been used since forever, bcm2711 config works perfectly on Pi 5, I've been making chips with it for a few months now without issues.

I don't get it - if you have a working vendor-provided RT kernel that you can just apt install, why bother building your own with a useless feature that no one needs?

Faults from stepper drivers are wired as inputs on mesa card. When fault is triggered mesa triggers emergency stop.

Ok you're telling me not to use a kernel that I have practical experience and have not had a single crash or anything similar. Neither have any users reported any crashes. I think an uptime of 39 days and being able to start Linuxcnc at anytime during that period with no crashes, latency errors or any other such issues proves to me that the kernel is solid and stable.
Before using it on the mill, I had been using to test some Mesa clones one based on a 7c81 and another more less based on the 7i92 design. I've also tested Ollie's riocore system, on the same 7c81 clone hardware early this year, before Oliie got his hands on a genuine Mesa 7c81 that he has made riocore formware for.
Could you point me to any papers, references or any such peer reviewed articles explaining why the 16k page kernel is broken by design.

So this time I will stand by my choices for the RPi5. Unless of course you can provide hard evidence as requested above.

Even this page says to config 2711 for RPi4 to RPi3 and 2712 for RPi5.
www.raspberrypi.com/documentation/computers/linux_kernel.html

Thank you very much for sharing Alan. Looking forward to more videos and the finished machine as I'm gathering parts and about to start building. Br, Henrik.

bcm2712_defconfig.txt is the 16k-page one, it's broken by design, don't use it that's also pretty much the only difference between it and 2711, look at the diff between the two.
bcm2711_rt_defconfig.txt works on both Pi versions, I've tested it on my setup. it's the one that linux-image-6.12.x+rpt-rpi-v8-rt is built from. I only use SPI though (with my own drivers that mmap the registers), so I'm not sure how Mesa cards or GPIO would behave.

After some testing and having my machine up for 39 days a network manager doesn't really affect latency, well at least on the RPi5 (I replaced the Odroid with the RPi5). And it does make it easier to turn wifi off when needed.

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.

I bought a spindle servo and i am unsure about the wiring on the 7i96s. Do I need 4 resistors for the 4 step/dir inputs or can I do it without them?

I connect 5V and 0V as well as step+, step-, dir+, and dir-. Which encoder outputs do I need for rigid tapping on the milling machine?
 
 

The issue has been with the live-build prior to the Trixie release.

The function that installs the firmware prior to Trixie doesn't blacklist unneeded firmware packages depending on the architecture. So when you run the installer from the ISO it installs all firmware packages regardless of architecture. This could have been mitigated by removing the raspi-firmware at the final stage of the installer by adding a line to preseed that instructs the installer to remove the raspi-firmware package. Basically what a user is needs to do when the error pops it's head up during an update.
On my bookworm machine instead of using the package that is in the bookworm repo I built a live-build package on bookworm using the Trixie sources. An extra line is added to the config, indicating that it's amd64 we're building an ISO for and the "blacklist function" kicks in and the raspi-firmware (and some others unrelated to amd64) are never installed when the installer is run from the ISO.

So to conclude:
It comes down to the version of live-build being used.
Bookworm version of live-build is (1:20230502), this causes the issue.
Trixie version of live-build is (1:20250505+deb13u1), this has no issues as long as --architectures amd64 is in the config file used by live build.
To install live-build (1:20250505+deb13u1) on Bookworm you need to build the package from source and install the package you just built. Also the additional line in the config file.

Building an ISO of a machine running Trixie that was successful gave me an idea as what the issue maybe. Installing the package for Trixie on Bookworm was no help, it was required to build from source.

I pretty much describe the issue in this post:
forum.linuxcnc.org/9-installing-linuxcnc...-iso?start=20#336448

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 .

Normally you would home the machine and then touch off on the workpiece origin. the buttons are there to do this but you can do it in gcode with G54
Maybe with your machine you always machine a full sheet but you still need to set the part origin. 

Sorry, I have no idea about the Pi... but I did get the 4b working years ago.