Advanced Search

First of all this is the first time I can recall this issue emerging.
I & many others I have used the image mentioned by the OP with no issues.

The screen going black isn't an indication that the Pi is bricked, there is a setting config.txt that controls whether you get the "rainbow" screen or not.

Generally there are issues which using the Rpi imager to write the image. If using windows Balena etcher is recommended, on Linux balena etcher can be used, dd is another alternative or whatever image writer that comes with your system.

To be pendantic, the bootloader is contained on the RPi board. As you have not mentioned any messages about of an out of date bootloader I doubt this is an issue.

One thing you could try, as you say you just recently bought a RPi5, is insert a blank SD card, connect an ethernet cable and boot. If you have the most recent bootloader the RPi5 should attempt to load an OS to the SD card via the internet.

pimylifeup.com/raspberry-pi-network-install/

One point to note, you get far far better bang for buck using a second hand corporate PC that a RPi5.

That is sort of what I tried. Unfortunately the new configs can only be made for a parallel port or a Mesa card.

Since this is a raspberry pi the parallel port won't run. I do have another working CNC that is running a Mesa, but that is operational and in use at the moment.

What I attempted here was to use the sample config I had to get a working gmoccapy, which worked fine, including jogging.

I then ran the wizard with the par_port option and qtPlasmac as the front end to create a default plasmac config.

I then replaced the par_port and associated hal nets, mainly just the joints and limits with the ones from the working gmoccapy config.

Unsure if there is a better way to achieve this.

Hello all, could use some help.  Currently in the final throws of getting a new build up and running:
QtPlasmaC V2.9-238.314
Raspberry Pi5
Mesa IO boards
Sheetcam and associated post processors

I realized that my THC was active on holes, which then led me to see that M67 commands weren't working for my holes.  Further investigating showed the following:

• M67 is working as I expect it to if G1 linear commands follow in lines below
• When a G3 is encountered, it resets feedrate to 100% and executes the arc at 100%
• I didn't test G2 yet
• If an inline M67 is issued with the G3, it will execute the arc at commanded rate.  For example, have the following as one line of code:
  • G3 X0.0 Y0.0 I-0.2 J-0.2 M67 E3 Q50
• However, after executing the above correctly it STILL resets feedrate back to 100%

I don't believe this is the expected behavior, my apologies if it is.  If it is the expected behavior, can someone point me to a Sheetcam post processor that would format it as such?

Thank you!

These are the exact commands I do:
git clone github.com/raspberrypi/linux.git -b rpi-6.12.y
cd linux
KERNEL=kernel_2712 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bcm2712_defconfig
KERNEL=kernel_2712 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

After that you choose fully preemptible.
Now I wonder what you do different I guess you didn't use the defconfig, then you should set EXPERT=y like I mentioned before: General Setup => Configure standard kernel features (expert users) and press Y, and Fully Preemptible is visible. But I advise to apply the changes to the defconfig at github.com/by/RT-Kernel except the rtc and ntp options, and use the defconfig.

To enable the realtime indicator I used the patch that I posted on page 2.
wget forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch
cd linux
git apply ../sys-kernel-realtime.patch

And to prevent compile errors (after the above patch) go at menuconfig to: General Setup =>  Kexec and crash features => press Y so CRASH_DUMP gets selected so VMCORE_INFO gets selected.

 So is there a bug in the PREEMPT_RT support in the 6.12 kernel, or is it simply not implemented the way LinuxCNC has come to expect? Obviously LinuxCNC needs to support a working standard.

This conversation is a bit confusing because rodw and I are doing different things to get the same result.

I am starting with Raspberry Pi OS, switching to their 6.12 branch then building the kernel to enable PREEMPT_RT. I'm doing this because they don't have a kernel build of 6.12 with realtime enabled yet.

rodw is starring with plain Debian and using a build system to create an image for the Raspberry Pi.

Sidenote: all realtime code is merged in upstream 6.12 now, but you still have to enable it at build time with a configuration option. There's no way to turn realtime on and off after it's built. 

These are Linux kernel patches, so I guess where the kernel devs hangout.

Hello,

Got the drive working again today, the parameters for Control Mode and Pulse Type were indeed wrong (so you were both right

Turns out that my backup parameters file was not good at all, I ended up just copying the working parameters from one of the X drives to the new Y drive. Both axis have the same mechanical setup, gear reduction ratio etc...

@ihavenofish : you are right, these drives have CAN bus capability. I made this choice at the time as I was not quite clear about the various options. Now, I wish I had chosen the E version that offers EtherCat...

I'm thinking about upgrading the whole setup to EtherCat, possibly running LinuxCNC from a RaspBerry. Pi. That would allow me to get rid of the PC/Parallel Port limitations, move all the hardware inside the control cabinet, and have more I/O to finally add some extras to the machine.

Thank you all for your help, great to see this community thriving !

Is there a GitHub tracking thread (or something else) for those patches?

I would be really interested in following that thread.

hahaha

These things happen.

We're making some headway towards getting a 6.12 kernel going with rod's image builder.
But despite what the recent skuttlebutt suggests for arm platforms it seems that some patches are still required for realtime.

I have made a mistake. I thought the kit I bought gave no *physical^ access to the SD card. But, it does.
My apologies for the trouble and misunderstanding.

Tom

I just installed linuxcnc on my desktop PC  using the Debian trixie alpha1 ISO on an AMD64 PC
Linuxcnc 2.3 is included in the trixie repositories
It installed fine and brought in the PREEMPT_RT kernel.
Linuxcnc started Using POSIX realtime with no further action

So it looks like its a Raspberry Pi thing which is resolved by applying the kernel patches. I'll try tonight

I just thought it was a little ironic as I posted about not being able to find any reference to any major hardware changes.

Cant do this anymore bye all wrote:

Just got info from 2 suppliers that there are 16GB RPi 5 for sale. No mention of any other hardware updates.

8 gb should be heaps. I havenever used more than 4 gb

Stand by. Trying to make a new pi5 image with all of our learnings
 

Just got info from 2 suppliers that there are 16GB RPi 5 for sale. No mention of any other hardware updates.

Cant do this anymore bye all wrote:

As far as I have been able to see there has been no major hardware updates to the RPi5. Or are you referring to the ability to boot from NVME ?
 

I think there has been a lot of improvement under the hood including making the 6.12 kernel available.But yeh, not something you can really see.