Advanced Search

@unknown Nope until now it's only at the master branch, when I see time I'll do a pull request for the 2.9 branch. You could possibly build from the 2.9 branch and apply the following patch with: git apply ../linuxcnc-rt-detect-6.12.patch

forum.linuxcnc.org/media/kunena/attachme...rt-detect-6.12.patch

Or just put "LINUXCNC_FORCE_REALTIME=1" in front of the LinuxCNC command of set it as a permanent environment setting

Hi Linux CNC forum, 

I'm building on a small CNC for over two years now. Unfortunately, I've been running in some issues while milling circular pockets.  
machine specs: 
Traj XYZA 
y-axis 1190 mm max travel, 20 mm ballscrew with 10 mm pitch, two 750W AC servo (HLTNC) 
x-axis 900 mm max travel, 20 mm ballscrew with 10 mm pitch, one 750W AC servo (HLTNC) 
z-axis 185 mm max travel, 16 mm ballscrew with 5 mm pitch, high torque nema 34 stepper 
spindle - 2,2 kw rattmotor air cooled
Brain of the operation: raspberry pi 4b+ using a parallel port hat and a 5 axis breakout board 
I'm running the premanufactured PI4 optimized Debian Bookworm image. 

Y-axis settings as follows: 
max_velocity = 5000 mm/min 
max_acc  = 20000 mm/min2
min limit = 0 mm
max limit = 1190 mm 
stepgen_maxaccel = 40000 
scale = 10 steps/mm -> (not sure why i set this to 10 -> 200 steps/rev and 10 mm pitch shall result in 20 steps/mm) 
FERROR = 1
Min_Ferror = 0.25

The issue: 
See attachment for further details 
arcs/circular shapes are for any reason shifted in XY - direction, the error occurs above 250 mm/min and is almost unchanged between 1000-5000 mm/min. 

What did i test up to now: 

1. Change base_period up and down -> the servos are set to 200 "steps"/rev, 10 mm pitch -> thus 20 steps/mm resulting in below 2000 pulses per second on one axis. Base_period is set to 100k, shall be fine? Changing the base_period to 40k didn't change anything as well as increasing the base period to 150k. 
2. Change max_acc to 4x max_velocity and stepgen to 2x max_acc -> didn't change anything 
3. check mechanical stiffness and backlash -> everything feels tight and rock solid, the linear guide rails are 20x30mm using very massiv long carriers. 
4. kill all unnecessary PIDs on the debain system in order to reduce latency -> didn't change anything

added the .hal and .ini file as attachments. 

Any hint or recommendation on how to improve this would be appreciated! 

Thank you!
Michael 








 

If you don't want to stick to Ethercat drives for all axes, really you should not have gone down the Ethercat route. Rtelligent and others have closed loop Ethercat stepper drivers. I would get a couple of them. Leadshine and Rtelligent also have open loop drives that control 2 x steppers in a single drive.

Rtelligent and Deiwu both have more affordable Ethercat I/O options

the 2.9.4 image or the Pi 5 has been released and is on the Downloads page. It includes the 6.12 kernel which has been built from the official Raspberry Pi kernel source
 

royka wrote:

If you build LinuxCNC now from Master you don't have to patch the kernel anymore from 6.12+.
To be clear, of course you still need a PREEMPT_RT built kernel.
 

Do you know if this has filtered down to 2.9.4 yet ?

KrisJ wrote:

I'm trying to follow Deje63's step by step to build the RT Kernel but I end up with an error:
"reversed (or previously applied patch detected) assume -R?" when trying to run command
"patch -p1 < ../patch-$RT_PATCH_VERSION.patch".
I'm not sure what it meant so I tried to patch anyway but end upp with make throwing "Error 2" at me,.on makefile:1921. Any idea what this might be and/or how to rectify it?

OR even better if anyone might be able to share an .img with LinuxCNC working with Rpi5 and built on RaspberryOS Lite.
I can't get the GPIO pins to work with the distro on the downloads page and it looks like in the man pages that a build on RpiOS is necessary for this to work...

Edit: attached Deje's txt-file for convenience. 

 

I can't get the GPIO pins to work this doesn't help.
and it looks like in the man pages that a build on RpiOS is necessary for this to work... This is not true

Output from a halrun session loading the driver

halcmd: loadrt hal_gpio inputs=GPIO5,GPIO6,GPIO12,GPIO13,GPIO16,GPIO17,GPIO18,GPIO19 \
halcmd+:                                 outputs=GPIO20,GPIO21,GPIO22,GPIO23,GPIO24,GPIO25,GPIO26,GPIO27 \
halcmd+:                                 invert=GPIO20,GPIO27 \
halcmd+:                                 reset=GPIO21,GPIO22
Note: Using POSIX realtime
halcmd: show pin
Component Pins:
Owner   Type  Dir         Value  Name
     4  bit   OUT         FALSE  hal_gpio.GPIO12-in
     4  bit   OUT         FALSE  hal_gpio.GPIO12-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO13-in
     4  bit   OUT         FALSE  hal_gpio.GPIO13-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO16-in
     4  bit   OUT         FALSE  hal_gpio.GPIO16-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO17-in
     4  bit   OUT         FALSE  hal_gpio.GPIO17-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO18-in
     4  bit   OUT         FALSE  hal_gpio.GPIO18-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO19-in
     4  bit   OUT         FALSE  hal_gpio.GPIO19-in-not
     4  bit   IN          FALSE  hal_gpio.GPIO20-out
     4  bit   IN          FALSE  hal_gpio.GPIO21-out
     4  bit   IN          FALSE  hal_gpio.GPIO22-out
     4  bit   IN          FALSE  hal_gpio.GPIO23-out
     4  bit   IN          FALSE  hal_gpio.GPIO24-out
     4  bit   IN          FALSE  hal_gpio.GPIO25-out
     4  bit   IN          FALSE  hal_gpio.GPIO26-out
     4  bit   IN          FALSE  hal_gpio.GPIO27-out
     4  bit   OUT         FALSE  hal_gpio.GPIO5-in
     4  bit   OUT         FALSE  hal_gpio.GPIO5-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO6-in
     4  bit   OUT         FALSE  hal_gpio.GPIO6-in-not
     4  s32   OUT             0  hal_gpio.read.time
     4  s32   OUT             0  hal_gpio.reset.time
     4  s32   OUT             0  hal_gpio.write.time

This is from the latest image. Now if something doesn't work, please please go into detail. How are we supposed to fix an issue when you don't elaborate on what happens ? I can't tell you how frustrating this is.

This driver wont work on the RPi5 hal_pi_gpio has it depend on the bcm2835 headers, which is applicable for the Rpi4 & Rpi3.

 

For your actual machine I wouldn't bother with step/dir and go straight to another servo ethercat. Sell yours and with 150 difference you are already setup.

For your second machine take a look at FlexiHAL, you can directly slap a raspi5 in it. also they are designing a new board with Rj45 for step/dir and another guy is designing a board to swap A6 step/dir to Rj45. Join the printNC discord the board creator is there

If you build LinuxCNC now from Master you don't have to patch the kernel anymore from 6.12+.
To be clear, of course you still need a PREEMPT_RT built kernel.

I'm trying to follow Deje63's step by step to build the RT Kernel but I end up with an error:
"reversed (or previously applied patch detected) assume -R?" when trying to run command
"patch -p1 < ../patch-$RT_PATCH_VERSION.patch".
I'm not sure what it meant so I tried to patch anyway but end upp with make throwing "Error 2" at me,.on makefile:1921. Any idea what this might be and/or how to rectify it?

OR even better if anyone might be able to share an .img with LinuxCNC working with Rpi5 and built on RaspberryOS Lite.
I can't get the GPIO pins to work with the distro on the downloads page and it looks like in the man pages that a build on RpiOS is necessary for this to work...

Edit: attached Deje's txt-file for convenience. 

Best bang for buck will be a RPi5 (if you didn't have a RPi5 I'd suggest an ex corporate PC) and either a Mesa Ethernet (preferred as you are not locked into a single platform)or SPI card. SPI & Mesa is supported on the RPi5 by the hm2_spix driver.

There are some other projects floating around Linuxcnc-RIO, but at the end of the day the Mesa cards are solid, well supported and don't look like disappearing soon.

Speaking from experience, regarding "roll your own" external motion cards, carefully work out a costing, sure the base FPGA card maybe cheaper than a Mesa card, but then you have to factor in all the other bits & bobs bring that up the same feature set.

Now I had a couple of Spartan FPGA dev boards floating around so adapting the Mesa SPI firmware and designing a couple of PCB's wasn't a great cost........but having to buy the parts to populate them was a different story. Getting a Mesa board to Australia is about $100 dollars just for postage alone last time I checked. To tell the truth it just started out as "can I get the firmware to run" then it snowballed.

I'm not trying to put you off but just some food for thought. Another point, delving into cnc is not cheap, so pricey can be kind of relative.

Mesa isn't a cult, it works, works well, is well supported by not only end users but by Pete from Mesa........who was kind enough to help me with a few questions regarding the project mentioned above. If my personal circumstances would allow it I'd be buying a few more Mesa cards to run my Lathe. The mill is fully equipped.

Good day all,

I wanted to share my experiences using the Raspberry Pi 5 to run my CNC machine and ask for some advice, as I am not sure where to go from here.

Please note, I am a novice at best!

To my surprise, I managed to set up LinuxCNC with EtherCAT to run my A6 servo motors that I got from StepperOnline. I am using the Probe Basic UI, and I love the setup so far. Big thanks to RodW for all the work and instructions on setting up EtherCAT.

I am also using an Arduino Mega connected to the Pi for general-purpose I/O—this also works great. (Using LinuxCNC_ArduinoConnector from: github.com/AlexmagToast/LinuxCNC_ArduinoConnector) This will mainly be used for buttons and tool changer I/O, so latency is not an issue. An EtherCAT I/O module would be better, but they are rather pricey.

What I would like to do is add a step/dir interface for my Z-axis, as this is still driven by a closed-loop stepper motor (my X and Y axes are EtherCAT). I want to be able to run the motor at a maximum of 200 kHz step rates. In the future, I would like to add a second Z-axis as well.

What I have tried:

• Using the GPIO pins from the Pi, but this does not generate step rates fast enough to run the motor. This also causes some latency issues, as the step generation is now done on the Pi.
• I switched out the Pi 5 for a Pi 4 (since SPI is not supported on the Pi 5) and tried using the Remora SPI interface to run a BTT SKR 1.4 as an external step generator. However, this also had a maximum step frequency that was too low. Additionally, I would prefer to use the Pi 5 instead of the Pi 4.

I would also like to build a second machine using only stepper motors with a step/dir interface. My motor drivers accept a maximum of 200 kHz.

I am looking for a solution that will allow me to run LinuxCNC on a Pi 5 with external step generation around 200 kHz that is not too pricey.

Any advice on which direction I should go next would be greatly appreciated.

Thanks for clearing that up Rod, it made sense in my mind, which was probably a bad sign.

As a band aid solution I extracted the files from the ethercat-dkms package and ran the update script in the directory for the boardcom stuff, which is a pain as the whole linux sources are need, not just the headers. Anyways some of the patches failed so I gave up on the theory.

unknown wrote:

As of Feb 4th 2025 the the 6.12.xx series kernel is not supported by Ethercat, so installation will fail. 

Only installation of Ethercat will fail. I have raised an issue with etherlabmaster on their gitlab repo asking if they have a time line for 6.12 support.
I alos pointed out they should get their finger out as Debian Trixie is only a few months away and it is currently running 6.12

As of Feb 4th 2025 the the 6.12.xx series kernel is not supported by Ethercat, so installation will fail. Those wanting Ethercat are encouraged to use the previous version. This is one of the pitfalls of creating images, if a older kernel is used people get upset, if a newer kernel is used people get upset. Eevn if we had of used the Rpi kernel that is "current", 6.6.x series, Ethercat would have the same issue.

Rodw is on to it and has raised the issue on the github repo.

www.linuxcnc.org/iso/rpi-4-debian-bookwo...23-11-17-1731.img.xz
www.linuxcnc.org/iso/rpi-5-debian-bookwo...23-11-17-1520.img.xz

"Does not work" is useless without further information. We do not read minds, I at least don't like playing 1000 questions.

If you have issues writing the image to an SD card, try extracting the image from the downloaded file (don't ask me I don't use windows), as the file is compressed to save space and time downloading, then try writing the image. If that fails check the sha256 sum. Tho if the file is corrupt extracting file will likely fail anyway. So check it first.
www.linuxcnc.org/iso/

There is a small patch to allwow the kernel to make a sysfs entry that Linuxcnc and some other programs use to determine if the kernel is a realtime kernel.

forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch

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