Advanced Search

The live build gets its code from the host that builds the system so to get a Trixie system, you need to be running Trixie. So I don't see why building for bookworm is not a problem.

In my testing back with the original installer (after some changes were made and committed to the release version), the pi firmware was not installed but it seemed after later bookworm versions were upgraded to, the firmware was  erroneously installed. And yes, I built the builder from source.

Why don't you try changing the architecture to arm64 and give the pi a go?

Yeah I could but I'd like to have a Trixe & Bookworm base image to work off. I'll get that going tomorrow (doesn't take too long) and have a look at the amd64 live-build for Trixie. Tho I'm a little desperate for disk space and had to drag a 2TB mechanical drive out of the cupboard.
This week's spending money went on RAM........so maybe in a couple of weeks I'll grab a NVMe drive.

Maybe if I stuck with Mach3 I wouldn't spend so much money, bugger I said the quiet part out load.

@langdons
Dude could you link to the main forum, there has been no lag issues for a while.

@Andy
Sorry I haven't had a chance to check with UEFI. I'll action it for tomorrow.

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.



 
 

If it wasn't intended for that purpose, then it should have been written somewhere, and if not, then that's a big minus for the manufacturer's karma! From the instructions:
“This header has a pin-out that matches a standard parallel port.”
And another question: why then does the official firmware 7i97t_5abobd have pins specifically for stepgen?
I am crying out from the bottom of my heart. This is my second machine. The first one was a simple board running Mach3. I wanted to make the new machine better. Meza turned out to be very suitable for this. I even managed to feel it after setting up the external PID loop. Now, in a foreign country and without any income, I am forced to turn down orders because I realize that I cannot guarantee the repair time for my machine.
Please let me know of any real sellers in Europe who sell Meza boards. Maybe this will speed up delivery and save on customs.
Thank You!

Then the big question is either an AMS type or multi extruders.

which version of LinuxCNC you're on? before 2.9.5 (I think) it required /sys/kernel/realtime to be present, which is not the case in the Pi kernels. if you're on 2.9.4, you can work around it by setting LINUXCNC_FORCE_REALTIME env var to 1 (I just do 'echo "export LINUXCNC_FORCE_REALTIME=1" >/etc/profile.d/linuxcnc-force-realtime.sh'), or update to a later version.

Video