Advanced Search

Thanks for the information.
I`m sure there are some facilities, but it`s probably only worth it, if your device costs several hundred dollars or is not available anymore. Google told me that simple repairs start from 120$ and more. A bit too much, unless I can be 100% sure that it works afterwards.

I`d love to send it to Mesa directly, but last time i wanted to order two cards, the shipping calculator presented me with a 250$ shipping fee. Todayy it`s 98$, but import taxes and tolls allways work in mysterious ways according to my experiences, so I refuse.

If nothing works, I can still use it as a huge I/O expander with a second ethernet port. I saw a video on youtube, where they connected two ethernet cards to the host with an ethernet switch. I think i read that one should avoid switches in favor of a direct connection, but my Raspberry only has one ethernet port. I will probably try it, if i order a new 7i76eu.

Anyway, thanks for the help.

After running a few tests, it appears that, in my case, the problem was caused by a missing software package. Installing gir1.2-rsvg-2.0 fixed the issue for me.

It is also worth mentioning that I installed Glade and configured it to use GTK 3.16 and WebKit2GTK 2.28.

For reference, I am running LinuxCNC 2.9.8 RMD on a Raspberry Pi 5.

Hopefully, this helps anyone experiencing a similar issue.

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.