Linuxcnc & the Raspberry Pi (4 & 5) Official Images Only!!!

I have been reading a lot about options with the RPi and LinuxCNC, and am just getting more confused so I thought I would just ask a couple of hopefully simple questions.

I have a 3-axis (sometimes 4 axis) mill currently running LinuxCNC on an OrangePi. It has been run with GRBL on an arduino, and an old PC with LinuxCNC. The current setup works okay with the OrangePi but the interface lags and I have some mods I want to eventually do to my mill. I have the newest official RPi image running on a RPi 4b. I need to eventually marry this to an external motion board but I decided to start off with software stepping using a Pi hat, but I know that won't last long. Basically I'm done screwing around and want to setup a system that is capable and expandable EASILY.

I've been looking at the Mesa 7C81 but that is probably overkill for my purposes, but if it is truly as easy as it seems it may be my final choice. So first question is if setup of the 7C81 is as easy as it seems with the PNC config wizard?

Second question I have is whether I have missed another option that is less overkill.  Here is what I eventually "complete" my mill

• LinuxCNC running with touchscreen interface without lag or problems. Would eventually like on-screen keyboard with a wireless keyboard/mouse usable if needed.
• 4 closed loop steppers (XYZ and a rotary table)
• 7 home/limit switches (2 each on XYZ, 1 on rotary table)
• Spindle control (VFD)
• Spindle encoder for tapping.
• 3 encoder wheels (for using the machine as a pseudo manual machine)  
• Maybe a dozen or so switches/buttons for input to LinuxCNC
• Only need about 40 kHz stepping rate max.
  
  Should I just stop thinking about it and buy the 7C81 when it comes back into stock? Or is there an almost as easy solution that will fit the above needs.
  
  BTW, I am also planning to CNC my lathe and would want to duplicate the setup the mill has on the lathe so I don't have to relearn anything.
  
  Thanks in advance.

The 7c81 will be fine. The only issue the wizzard doesn't support the 7c81 but you can pick a 5i25 in the wizzard and edit the files after to suit, just replace 5i25 with 7c81 and change the loading of the driver to suit.

I actually made a "homemade clone" of a 7c81 using an FPGA board from Aliexpress and some custom boards. The only difficult part was modding the hostmot2 sources to suit. Pete from Mesa was helpful with this project and I'm very appreciative of the support he give on these projects. My reason for going this way is it was a cheaper option, freight to Australia almost doubles the price, and I was looking for a "challenge". BTW the same hardware will work with the Linuxcnc-RIO project, and with the addition on a Wiznet ethernet module it allows for an ethernet option with the Linuxcnc-RIO project but not with the standard hostmot2 firmware (that would require some work on the Linuxcnc side and the FPGA side)
github.com/ozzyrob/Linuxcnc-FPGA

When using software stepping the upper limit will depend on the base thread period you can work with on the RPi4.

All The Best
Rob

I was asked to post in this thread about a problem I encountered with installing the official LinuxCNC image for the Raspberry Pi 4b. 

The issue I had was once the image was burned to the SD and booted the monitor that I have for the RPi was skewed on the login screen. It looked like the picture below. You could make out what it was showing and could log in and it would take you to the desktop but it was also skewed. You could make out what was there and navigate to the display settings, change the resolution, and get it working, but the changes were not persistent. Everytime the RPi booted it would revert back to the skewed resolution.

It was suggested that the HDMI cable could be at fault, and this is a good suggestion. I did try a couple different HDMI cables with the same results. 

I tried a lot of things from internet searches about this problem, but nothing seemed to work, but I finally found a clue from one post in the internet that was hard to find. I wound up changing several things in the config.txt file in the top level directory of the SD card. I used a Windows laptop to make the changes. Once I had it working, I reversed the changes one by one to see which change was the one that actually fixed it. Here is what I found:

In config.txt you will find this section in there with notes about what I changed to fix it:
[pi4]
dtoverlay=vc4-kms-v3d,cma-512              Comment out this line
#dtoverlay=vc4-kms-v3d-pi4
#dtoverlay=vc4-fkms-v3d                          Uncomment this line
max_framebuffers=2
arm_boost=1
#disable_fw_kms_setup=1

As I understand it this forces the use of an older display driver.

I believe this problem was due to an incompatability between the display I was using (Cheap Chinese 10 display) and the newest driver on the RPi. Forcing it to use the older driver got it working perfectly.

BTW, I also tried the same SD card on my son's RPi 5 and had no problems even with the unmodified config.txt.

Incidentally, the display I was using is a cheap one I use as a second display when I travel for work. I bought cheap because it is likely to get busted up in luggage some day. For my final LinuxCNC display I will be using a different touch screen display. Hopefully that one will work well.

I hope this will be helpful to anyone who may encounter the same problem.

Thanks Rob. I'll get the 7C81 when it comes back in stock.

I thought that I saw somewhere that the 7C81 is now supported in the PNC config Wizard. I could easily be wrong though.

Thanks.

zram issue Sat Feb 22, 2025

Big thanks to forum user spina for finding this.
Tho not a game stopper, doesn't seem to affect the operation. Just entries into /var/log/boot.log
Is related to swap.
So far no reports of adverse behavior has been reported.

A reboot can be done now or you can edit the file mentioned below to prior to rebooting.

By default up to 4GB of ram or half the ram is used, depending on how much ram one has.

On my 4GB system I have the following entry, which allocates 1GB to zram swap......the file to edit is after the # symbol.
Apologies for missing this prior to releasing the images.

Sorry, my research says zram is not installed by default on Raspberry OS. I don't see this is a Linuxcnc issue.
We've always said to use a 4 GB system and with that much ram, mamory caching is not required.

Actually it's my issue for not checking the boot logs, the scripts setup the zram.service. Whether Raspberry OS uses zram is not related to our images, as we use Debian.....as of course you know.
The zram.service is part of the image builder, I've modified the process so the service shouldn't be enabled and later on install systemd-zram-generator and create a config that will use 1GB on a 4GB system, this can be modified if required.
As you can see zram tools are installed, this is whether or not systemd-zram-tools are installed.
The issue is because Bookworm uses systemd the package systemd-zram-generator is required, this is the missing piece of the puzzle. During the build the a different script is used to zram0 which fails.

As you can see from below zram0 is used for swap.
Without the mods I've describe above there is no swap. Whether it's need or not, but on a typical debian x86_64 install usually a 1GB swap partition is created.

As you can see it really doesn't affect the total free memory when it's not in use.And BTW it not caching memory nor mamory glands, but is creating a swap partition that is compressed in memory.

The simplest option is just to mark zram.service as masked and have no swap.

So at the moment I'm building an image with the mods.....and make sure I've done it right.

Rob

zram is a kernel option which can be disabled by adding zram.enabled=0 to boot.txt
Do you guys want to try that?
The Debian tools are not really necessary. The kernel docs explain how to configure it manually.
www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html

No, it has nothing to do with the kernel module, disabling the kernel module won't stop the service running. The messages are coming from the service systemd is attempting to start.
One option is to mask the service and have no swap available.
The second option is as I've described and have a little swap if needed.
But it's not the kernel modules that are issue.
Not to be unkind but I didn't pull the solution out of my backside, I spent some time researching the issue, as to what was causing the issue, how to fix the issue and what was supposed to be happening.
The service is for setting up swap in compressed ram. Whilst there is a little overhead in compressing and decompressing the speed for accessing ram is far far quicker than accessing a drive of any sort. If no swapping occurs it will have no affect on latency.
And even before I offered up my solution I ran a few tests to make sure I had the method correct and there were no issues with latency or anything else.
And yes I should have been more vigilant when initially putting everything together.

PLEASE NOTE
all references to zram.service should be zramswap.service

Simple Mesa Setup



Thanks to PWC

You definitely do not want DHCP and you do
need to set a static address.

You might try this:
DO NOT set a gateway or nameservers