Advanced Search

Is it a Pi5 or 4b? the 4b was always a bit marginal but some say the 5 is flawless for them.

You could try the Respberry way perhaps. Once you get the RT kernel sorted, just compile linuxcnc

forums.raspberrypi.com/viewtopic.php?t=396623

I tried this method (but did RIP instead):

forum.linuxcnc.org/9-installing-linuxcnc...th-preempt-rt-kernel

and the latency was horrid. The thread is from Dec 2022 thought it seems, so maybe there is a better way?

The latency isn't very good on the 2.9.8 image from the downloads page either, but not as bad as it was following the above guide. Maybe that's to be expected?

Everything just feels sluggish, and "jerky".

I created the original 2.9.2 image, but have not touched it since. I don't have a pi to do anything further. I think Andy may have rebuilt later versions.
We had no choice but to build the kernel from the official pi source back then.
I think there could be better ways to do this as preempt_rt is now supported.

I would not worry about it just use it. Keep a spare SD card preconfigured. The only thing you need to do is keep a copy of your ~/linuxcnc folder

I've had a Pi4B running for 4 years on a standard 16gB SD card and it never failed. There is far more transactional data happening there.

tommylight wrote:

Not me.

But surely someone knows who does it.

Not me.

Who creates the RPi4/5 image here:

linuxcnc.org/downloads/

Greetings,
This is my first post so I'm hoping I done break any protocols...

I have converted a 1959 vintage Centec AutoMill (3 axis horizontal milling machine) to CNC using LinuxCNC 2.9.10 Debian 13 Trixie PREEMPT-RT on a Raspberry Pi5 with 8 gig of ram, directly controlling three GeckoDrive 201x stepper drives via the Pi's GPIO pins. It is working very well as the Gecko 201x works with 3.3 volt logic and I very pleased with its performance. No need for a MESA board or any kind of logic level shifting.

I recently read that the Micro SD cards used in the Pi are not well suited to handle lots of read/write activity, and over time will fail.

Can anyone tell me if LinuxCNC does a lot of writing/reading of things like temporary files during the running of the machine?

TIA   Greg

I would have thought that with "Raspberry PI with GPIO" you would have already had your cheap low-cost HW assisted engine.  If you must use a PC and don't want to find one with a parallel port, low-end Mesa cards are my suggestion (like the 7i92TH or 7i96S).  I think with Remora you'd "get what you paid for" and eventually a low-end Mesa card would be a better bargain, and much more turn-key and supported.
 

Thanks for your response. I realize that an old PC with parallel port works. Counting on an old PC going forward is not something that appeals to me. I also understand that the Mesa card is solid but the price is less than desirable. Noting that I am not an expert, it seems that the Remora with RP2040 over ethernet should be up to the job and be far cheaper than the Mesa cards. Unfortunately,, I don't have the skills to write the SW so the question remains: Is/or will be Remora with RP2040 ready for prime time? Note: currently I have the Raspberry Pi 5 running Linuxcnc using its GPIO port (buffered with some simple buffer HW but not aux processor) and it will probably meet my needs. That said, a solution based on a cheap aux processor would be a big benefit.

There is little more than a single bug fix in 2.10 so unless that is going to affect you which it probably isn't, just get your Mesa card up and running with the working system you have.

The whole point of version 2.9.10 was that the 'single bug' could crash a users machine. So if the 'which it probably isn't,' turns out to be a wrong assumption then it might actually crash your machine if you happen to use existing probing routines.

Thanks very much for your knowledge and advice rodw!

I'm taking it to heart and will NOT update for now.

I'm going to continue posting progress and I hope you'll find it entertaining rather than laughable!

Thanks for the reply. I now also monitored the GPIOs.

Correction to my earlier post in this thread first: the InM is not frozen. That was a monitoring-timing mistake on my end — IN4 (E-stop) tracks perfectly in both inm.00.input-04 and gpio.004.in. Card, InM and Ethernet are all fine.

System: LinuxCNC 2.9.10 (uspace), Raspberry Pi CM5, Debian 12 PREEMPT_RT, 7I96S via hm2_eth.
config="num_encoders=1 num_pwmgens=1 num_stepgens=5 sserial_port_0=0xxxxxxx"

Bank is wired sourcing (common on 0 V) — confirmed by several known-good and working inputs:

E-stop: 24V+ → NC switch → IN4. Released (24 V on pin) → TRUE; pressed (open) → FALSE. Tracks perfectly.
Driver alarms: 24V+ → ALM → IN0–3, working.

Problem input: IN8 has an M8 NPN-NC inductive sensor (sinking). Bare, its target-present level only reached ~13 V, so it read active in both states; I added a ~470 Ω pull-up from the pin to +24 V. The pin now measures:

target absent: 0.1 V
target present: 23.85 V

The sensor's own LED and the card's IN8 input LED both follow the target correctly — but inm.00.input-08 and gpio.008.in read stuck TRUE regardless.

Thanks, heaps, for the info. I have a working config for Ethercat on my raspberry pi 5, So I will play around with connecting a tang 9k to the spi on the pi and see how I go. I will post more info if/when i get it working.
Thanks again.
Andrew

There is little more than a single bug fix in 2.10 so unless that is going to affect you which it probably isn't, just get your Mesa card up and running with the working system you have.