Advanced Search

Hello @cornholio:

I do understand some of the things you are saying. 

I'm not a LinuxCNC'er so please bear with me.

A start might be to enumerate types of users as I see them:

Gold users just want to get something done (say make parts for a space station). Their CNC machines are already supported by LinuxCNC. They would appreciate a working version of LinuxCNC. Once they get it they probably will not change it over time unless they need to support new devices or new features.

The key here is that installing and getting LinuxCNC running should be as easy as it is to get Raspberry Pi 5 or Ubuntu up in the first place. (I'm not sure if my experience getting RPi5 up is similar to getting RPi4 up but more on that later).

If a newcomer can not get a version going enough to run say a "Maslow" machine (please Google "maslow cnc kit") then work still needs to be done.

Silver users/developers know and contribute to the LinuxCNC GitHub repo. The users have absolute control of the repo and the CNC, sysgen and testing features merged into it.

Bronze users/developers know and contribute to the Linux GitHub repo. The users have absolute control of the repo and the OS, sysgen and testing features merged into it.

The question comes: How to manage the need for support between Gold, Silver and Bronze users. I'm not sure of a solution here but I believe some solution will arise.

Tests should exist that (all) developers can run and get understandable results from. The only issue should be coverage at a given point in time. Hopefully the more tests you develop and manage the better off everyone should be.

I realize some of the above exists. It just needs to be pulled together.

An observation about configuration files: I think they may have gotten a bit out of hand.

I believe plain text files are easier for users to work with than XML but, a coherent "system build, installation and configuration" facility may be easier to develop and maintain if the configuration is rationally represented by some data handling facility (not a DBMS).

Please let me know your thoughts up to this point.

Many thanks,
Tom

Hi Guys, I'm pretty new here and just getting started with LinuxCNC, I've been retro fitting a rf31 mill and have a NVEM V2 I was using with Mach3 on an old laptop. the laptop started to play up and lost all my motor settings so i decided to ditch it all and buy a Raspberry Pi 5, load it with LinuxCNC and set it up solely for this machine.
I recently got my STlink all setup and now I need to confirm which bin file I need to download from GitHub? is it the Remora-NVEM-STM32-1.0.0.bin file in the Remora-NVEM/firmware directory or the Remora-NVEM.bin file in the Remora-NVEM/Remora-NVEM-STM32/Firmware directory? 
I'm going off the Scott 3D Youtube videos, but the GitHub info seems to be a bit out of date. Is any of the info in those videos still up to date or should I be looking elsewhere?
Thanks

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. 

royka wrote:

Like you assumed before I think those patches indeed didn't make it to the mainline kernel, but those are not needed to make a fully preemptible kernel.

The sysfs patch is only needed because LinuxCNC checks that indicator. Later I saw that the source of Raspberry also already has the arch_supports_rt in the kconfig.
 

Whilst it does have that it's not the correct value.....from the required patch I've used with 6.1.69 

royka wrote:

For Raspberry I think following this guide should help: github.com/by/RT-Kernel

Only after git clone, download this patch:
forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch
Then enter the Linux folder and enter: git apply ../sys-kernel-realtime.patch
After make menuconfig make sure that these are also selected:
forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=10#315643

This does not work in all build environments. I think Cornholio is correct

Like you assumed before I think those patches indeed didn't make it to the mainline kernel, but those are not needed to make a fully preemptible kernel.

The sysfs patch is only needed because LinuxCNC checks that indicator. Later I saw that the source of Raspberry also already has the arch_supports_rt in the kconfig.

For Raspberry I think following this guide should help: github.com/by/RT-Kernel

Only after git clone, download this patch:
forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch
Then enter the Linux folder and enter: git apply ../sys-kernel-realtime.patch
After make menuconfig make sure that these are also selected:
forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=10#315643

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.