Advanced Search

Your could just upgrade Bookworm  to Trixie with sudo apt dist-upgrade for testing

Use a Meanwell power supply. Say a MDR-15-5 which is 2.4 amps

I've been playing with pi-gen.....I think it is a little better, you get a more raspberry pi like experience. There's a link in my proposal thread. ATM the moment I've been building upto the "lite" stage burning & booting and installing the desktop,Xorg and the rest. Linuxcnc has been from the debian repo.....But I should be able to fine tune things.

Bookworm has been the target so far, Trixie shouldn't be an issue, but one thing I really need to know is the status of linuxcnc.org/docs/2.9/html/drivers/hal_gpio.html . I think there was an issue with the libgpiod library.
Bookworm version is 1.6.3-1
Trixie version is 2.2.1-2

You can burn to your boot device sing RPI-Imager and edit settings such via the imager.

There's realtime kernels available via the raspberry kernel repo. The Rpi4 4k page kernels run on the Rpi5.......so we may only need one image to cover both boards.

win32diskimager was my go to for years but it has let me down with later versions. I recommend you use Balena Etcher which is available for Windows, Linux and Mac.

I discussed its use in my latest video

andypugh wrote:

f355 wrote:

I have a feeling that the package for the Pi in www.linuxcnc.org/dists/trixie might be the Bookworm package rather than one built on Pi/Trixie. I don't know how that happened at this point, I might just have been hoping that it would work and have now found out otherwise 


 

I think you would need to edit the release variable in the userdata.txt file but you'd also need to sync our repo to the upstream sources

At the time, there was no way to build an image file that included custom software.
The image builder we created is based on a fork of github.com/pyavitz/rpi-img-builder The original author gave us amazing support and advice. This repo builds the kernel from source and we had to patch the kernel to produce a PREEMPT_RT version. This proved tricky because the kernel version needed to match a version of the RT patch so we had to ensure we got the  Pi kernel code at a specific commit.
This is a cross compiler environment on amd64  as doing what we do would likely take days on a pi.

At the time, there was no LinuxCNC Deb file (linuxcnc-uspace) for the Pi so we had no choice but to build from source. I still don't believe we have a buildbot building for the Pi.

Today, you may be able to use the Debian build system we use for amd64 because the RT kernel and linuxcnc-uspace v 2.94 are in the debian repos. It uses a chroot, so it may permit building on amd64 but I have never seen settings for that. 

Cheers
Ok that worked, funny thing is the RPi5 that runs with the official image, with the kernel I built, does have /sys/kernel/realtime present.

Ahh that's right my kernel guru explained it earlier.

forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=10#315437


Now, since you mentioned 6.12.47 seemed to crash, would you think it would be an idea the pin the kernel to 6.12.34 ?

Tho there does seem to to be 6.12.54.........natively ran a build using the sources pacakge from the raspi kernel repo.

But me thinks I'll stick to the basics for the time being.

I had a bit of time to study your notes. optimizing probing speeds (time is money for production right?) requires careful attention and trial and error to set probe heights and probe speeds. This video shows the best I got it down to (2.0mm mild steel)



The reason why it sets the material  height on up travel when the contact is broken, is  that on a larger sheet, you can get a lot of  warping (up to 100m) and  the sheet is no longer supported by the slats. Even 16mm steel warps.... In this case, the material can bend down on probing which means that you could register a height that is well below the material height when cutting. Setting the height on uptravel eliminates errors from the springiness.

If you observe the torch while probing on a wet sheet, the water can form a meniscus around the torch tip that is dragged up and it can break away from the torch well above the material surface which will explain height variations. Experiment with a MPG on the Z axis to see this.

Note that the purpose of pulsing the torch is to activate preflow air before the cut so water is blown away from the torch as this video demonstrates.



As you can see, there are a lot of things to consider.

On an ethercat drive, it would be interesting to experiment with torque mode homing so the bottom home or limit switch set the material height.