Advanced Search

ruffle wrote:

The 'normal' Raspian stylee dd from the SDCard to a USB SSD doesn't result in a bootable USB device but sticking Cornholio's .img on a USB SSD does boot... but didn't auto-resize the root partition a parted and resize2fs sorted that (no not idea but it worked!).
 

I thought the "normal" Raspberian style would use rpi-imager www.raspberrypi.com/software/
Balena Etcher is also an alternative which runs on any platform and is way faster than dd

I am using linuxCNC 2.9pre on raspberry i build latetest build and copied hostmot2.so and hm2_eth.so to make pktuart to work, could that cause problems ?

Sorry there. My intention is to get this accepted as the official rpi builder for linuxcnc to replace this old one github.com/LinuxCNC/raspberrypi-linux  I don't think its even 64 bit. But ideally, it will be fully configured, ready to go and just using the user configurable features so there is no hacking into any core scripts.

There has been so many images shared around but some are dated and the build process is never shared and its never been based on the official builder like this one.

I'm building another image for the x86 I have to get back to. Its been reviewed by one of the main developers so it needs a couple of things polished.

But what excites me is  C0nelius upstream has another more generic ARM image builder so I'm keen to gve it a go for my 6 core Odroid N2+ which is gathering dust.

cornholio wrote:

I think it'll be better to just have one image, support will be easier. Well just my opinion.

We are using the Raspberry Pi repositories. Debian it is! Thats what they give us! Thats what we use!

Did I fall into a misconception? After the installation of Debian 12 and LinuxCNC, I've spent a significant amount of time dealing with latency and fluctuation issues in the testing software without actually testing it on the machine. If the data shown in the picture doesn't affect subsequent use, then I can proceed confidently to the next step. I might have expressed myself wrongly just now. I will be using GPIO and ethercat in the future. I sincerely apologize.

Does your previous test data above not affect the subsequent use of Mesa or EtherCAT?

I don't know the pi well but developed the Debian 12 installer using the debian images and pioneered the approach Cornholio is using to make the Debian image.

What I don't understand is why you would use software stepping on a pi. Wouldn't you be better off using a hardware or timer interupt on the GPIO pins? Andy Pugh has a new device driver for gpiod but I think he's stilll working on how to get it to build within linuxcnc
github.com/LinuxCNC/linuxcnc/blob/andypu...l/drivers/hal_gpio.c
This is the more generic approach to deal with gpio on most SBC's
He says this reads in 16 usec and writes in 8 usec.  I have run steppers with a simple on/off square wave pulse (2 writes per pulse) but linuxcnc is a bit smarter and sets a shorter pulse in the operating frequency. I think that is still only 2  writes per step. That gets you up to around 62 kHz step max frequency. I think that would be quite a reasonable performance. My tests found step frequency was limited to about 90-100 kHz from memory for a stepper. You guys should investigate how feasible that would be to implement. Me, I will stick to Mesa or ethercat.
 

No worries mate, maybe someone else will chime in with far better answers than myself.

This is a new continent, I will continue to try.

Did you isolate another Core ? As built only 2 cores are isolated.

If you really need to use software stepping you can try upping the base thread but that will lower your step frequency.
latency-histogram --base 30000

Or as another option have a look around the forum there might be another image based on Raspbian OS that is Debian 11 (bullseye) that might get you better results.

There's some info here wiki.linuxaudio.org/wiki/raspberrypi whilst it's aimed at audio applications you might get some luck. To be honest an external motion card will more than likely be the better option as latency isn't such a big issue.

Another thing to think about is the Debian kernels don't appear to allow loading of overlays, the kernel from the Raspberry guys have the patch for the required infrastructure.

I tested it, and the runtime seems to be about the same as what I built myself.

Just test & see. You may have to raise your base thread a little to work with software stepping.

Thank you for your help and guidance. I'll start testing immediately. Is it necessary to disable wifi to improve latency? Wifi is very important to me. I might use external devices for stepper motor control in the future.

drive.google.com/file/d/1i4flcwKPysOzlks.../view?usp=drive_link
user:cnc
passwd:linuxcnc

has 2 cores isolated.

cmdline.txt is here (can change to isolate up 3 cores)
/boot/broadcom/cmdline.txt

config.txt you can turn wifi off here
/boot/broadcom/config.txt

Just reboot after editing files as sudo

Is built form ofiicial Rpi kernel sources with kernel.org real time patch. Pretty much Debian 12 with an xfce desktop and Linuxcnc 2.9 pre-installed. Looking or those willing to test. I've only got a RP400 to test with that has a slightly faster core compared to a Raspberry Pi-4B.

Are you planning on software stepping via GPIO ?
If you are going to use an external motion control board for stepping you will only need a servo thread and latency is pretty relaxed.

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm

uname -a
Linux armcnc 6.1.0-10-rt-arm64 #1 SMP PREEMPT_RT Debian 6.1.38-1 (2023-07-14) aarch64 GNU/Linux