Advanced Search

I recently struggled with getting my Raspberry Pi 5 to accept the estop input. On this forum, I asked the following question. 
I would like to know how to connect the GPIO to LinuxCNC’s E-Stop chain.
From this, I received some tips and advice that pointed me in the right direction, but no working answers. I used a YouTube video on installing LinuxCNC on a Raspberry Pi, but the advice was old and no longer valid. My assessment at this time is: If someone were to attempt what I attempted, I don't see a mechanism for them to follow in my footsteps because they would unlikely use the search term "estop" or "GPIO" to search the forum. So I would like to put together what I learned to make this happen. 
1. Not many users of this form are using Raspberry Pi computers - they have some limitations
2. The Byte2Bot hat does not create a parallel port. Rather is isolates the GPIO pins on the computer board and brings them out using a DB25 connector that is just like the parallel port on your Mesa card or computer. This allows you to use a parallel port breakout board. While a parallel port dedicates PIN2 to a dataline, with the output from a Raspberry Pi, one needs to refer to what is the GPIO line connected to that pin which is GPIO9 in this example. In your setup, you cannot refer to PIN2; you must only refer to which GPIO line it is. When someone sends you suggestions that look like  "=> hal-gpio.PIN12.out" - it won't help you. 
3. There are folks who can help you. The most valuable was the user "unkown". unknown provided this:
Below is a thread that is more or less an index for the Main RPi4/5 thread.
forum.linuxcnc.org/38-general-linuxcnc-q...l-images-only#325007
Has a section regarding GPIO and there is a working config if you follow the links.
They are there, you just have to look.
Just about everything regarding the Rpi4/5 is in this thread
forum.linuxcnc.org/9-installing-linuxcnc...official-images-only
4. The schematic offered by Byte2Bot had some notable omissions that is corrected in the Circuit3.jpg schematic from another user.
5. The eStop button should be NC (Normally Closed) - I did not correct that. The eStop button should be latching - mine is not. 
6. The *.hal file has changed significantly since the requirement of using the GPIO nomenclature
7. I have yet to control the spindle speed with the breakout board.
8. The StepConfig package in LinuxCNC is not intended for a Raspberry Pi with a hat. It is designed for a MESA board setup, which this is not. I'm not aware of a reason to use it, but it does create a *.hal and *.ini file for the machine name you select in setup.
9. If you want to search Google about eStop, do not search "Linuxcnc estop". You will fail. However, if you add the word "latch" to your query, you will have success. Don't ask. If you have a ton of experience, it may make sense. 
10.  When you submit a topic, hit the submit button and go have lunch. Nothing may happen for a while. I became impatient and hit submit again, and two instances of my topic were submitted. 11. How your question looks in the editor may not be how it looks online.12. I have more to learn.

SO
What do I have to promote the cause? If you use a Raspberry Pi 5 with a Byte2Bot parallel hat (it should be called a DB25 hat) with a parallel breakout board, you may have success with the following wiring and code.

Hi all,I have a working Remora configuration running with Raspberry Pi (LinuxCNC 2.9), SKR 1.4 board (LPC1768), and SPI connection – but only using an old Remora component, because the recent ones do not support LPC1768 anymore (as Scott confirmed). The system works perfectly “on the bench” with just the boards and motors, but as soon as I connect it to my real machine, the SPI link becomes super unstable (“bad SPI payload / estop won’t reset” errors).Symptoms:

• Dupont wires or short IDC ribbon cable used for SPI (RPi CM4 → SKR1.4, <30cm).
• Works fine with just the controller and stepper drivers.
• The moment I connect “real loads” (motors, hotwire, power MOSFETs, or even touch the machine frame), SPI constantly fails.
• E-stop triggers, payload errors jump in LinuxCNC log.
• Even switching on the heater causes instant SPI dropouts.
• With ribbon cable it’s even worse (won’t leave estop).

What I tried:

• Multiple cables, power supplies, SD cards, re-flashing, common ground.
• SPI config is what works for old component – I can’t change SPI freq etc, I get “unknown command” if I try.
• System is totally stable on the bench, not with machine.

Limitations:

• New Remora components don't work – the SKR1.4/LPC1768 is legacy, so I must use the oldest one.
• This old Remora doesn’t let me change SPI speed, delay, etc.
• Hardware fix suggestions welcome, but software/firmware is stuck “as is” for now.

Has anyone solved this?

• Is it possible to get reliable SPI with legacy SKR1.4 + RPi, in a noisy CNC environment?
• Any proven hardware methods? (twisted pairs, shielded cable, ground, ferrites, extra pullups, RC on SPI lines…?)
• Is it possible to patch the Remora legacy component to allow lower SPI clock?
• Any old firmware/component version which allows SPI configuration and works with LPC1768?

Any advice would help – right now the setup works great “bare”, but physical machine (motors/heaters/vibrations) kills SPI instantly…Thanks!

forum.linuxcnc.org/27-driver-boards/3889...7c81?start=20#195102

Put it this way, if the RPi5 goes bad for whatever reason, you'll have to get a new Raspberry whatever, but if you go with the 7i96 any machine with an Ethernet Port will slip in, copy your config over and you're good to go. Hardware step generation, Mesa, et al, will be smoother than software step generation.

gravedigger wrote:

Das RASPI PI5 läuft absolut unzuverlässig  und stürzt unvermittelt ab mit einer zweiten Netzwerkkarte, aber das WLAN hab ich als Anfänger nicht hinbekommen mit den Anleitungen.
Dann hab ich das offizielle Image 2.9.2 mit einem Micro-PC verwendet und auf 2.9.7 upgedatet, welches aber auch wieder irgendwelche Fehlermeldungen produziert und die Ethernetverbindung zur Mesa abbricht (Realtek Treiber und RASPI Image Meldung).

 

Bei mir läuft das Debian 12 sehr stabil. Ich habe testweise das aktuelle, auf Debian 13 basierte Image kurz getestet, habe mit dem Raspberry 5 8Gb extrem schlechte Latenz.
Was WLAN angeht, ist das eher ein Hardwareproblem. Meiner muss schon 10cm so neben dem Router liegen, damit er sich mit dem Netzwerk verbindet. Bluetooth ist auch sehr schwach. Meine Kopfhörer haben Aussetzer und sobald irgendetwas zwischen Raspberry und Kopfhörer liegt, bricht die Verbindung komplett zusammen. Ich vermute, das ist beim Raspberry entweder absichtlich so gemacht, damit er weniger Strom verbraucht, oder irgendein BGA ist schlecht verlötet.Wenn du eine zusätzliche Netzwerkkarte und einen SSD Adapter huckepack hast, schirmen die das Signal zusätzlich ab. Evenetuell hat eine davon einen Defekt oder einen schlechtern Treiber, worauf die Instabilitäten zurückzuführen sind? 

I'm looking for suggestions for a simple bread & butter Linux CNC install.

It seems like an Raspberry Pi 5 + Mesa 7i96S might be the current standard, but it's not super clear? A while back it seemed like the Beaglebone was a good option, but it seems things have not gone that way?

Background...
I've built/retrofitted a number of machines with Linux CNC, but not for perhaps 10 years.  I've done a lot of machining and I'm fully competent with Linux.

I've got a new project that wants to integrate 2 Sherline CNC chucker lathes with some additional widgets.  Each lathe would get its own LinuxCNC hardware & software and the integration would be via ssh/linux command line.

If I can get the system working well, I might get orders for 10 or 50 of these systems over the next few years, so I would really like to use a stable, easy to get, standardized off-the-shelf parts, that can be expected to remain available for the next 5 years. I'm *not* looking to cobble something together out of 10 year old PCs, and I'd prefer not to build on some wierd/cheapo/legacy PC off Amazon which may go away in 3 months.

I'm looking for a simple reliable bread & butter LinuxCNC platform.

Suggestions?

BB

Hi,
Where can i get the updated firmware?
I have connected the 7C80 to raspberry Pi 5.
Thank you,

Hi everyone,I’ve recently finished mounting my machine to its base and tidying up the wiring, so I decided to try running a quick program to see if everything was working properly.Machine Configuration:

• Controller: Raspberry Pi 5
• Servos: 3 × Leadshine EL8 servo drives with 400 W motors (EtherCAT)
• Spindle: 1 kW StepperOnline drive (EtherCAT)

The program starts fine, but the machine seems to get stuck at the first G1 command.After doing some reading, it looks like this could be related to the “spindle-at-speed” signal in the HAL configuration.Because I’m using EtherCAT, I’m not sure where this needs to be handled:
Should the spindle-at-speed signal be configured in the HAL file, or Is it something that needs to be set up in the .comp file for the EtherCAT drive?

Any guidance or examples on how to handle this signal within an EtherCAT setup would be really appreciated. when the spindle is running currently I am having no feedback from the drive to record the actual speed ? 

Hi Scott and all,

thanks for the previous reply about SKR1.4 / LPC1768 being “legacy” and only supported by the older Remora component. I went back to an older Remora version that still supports the LPC1768 and now SPI communication basically works – LinuxCNC starts, the joints move etc.

However, I am now fighting with heavy EMI / noise on the SPI link and I keep getting “Bad SPI payload / estop won’t reset” as soon as the machine does any real work.

Hardware setup:

Controller: Raspberry Pi (LinuxCNC 2.9.x, RPi CM4)

Remora board: BTT SKR 1.4 (LPC1768)

Connection between RPi and SKR: currently Dupont jumper wires (I also tried a short IDC ribbon cable – even worse, estop does not clear at all)

Remora Component: Remora for LPC176x release, version 0.1.0, from Oct 17, 2021

Symptoms:

With just the electronics on the bench, SPI works and LinuxCNC runs.

When I connect the SKR to the real hot‑wire foam cutter mechanics (5 stepper drivers + hot wire power), I start getting random SPI errors:

“Bad SPI payload”

communication drops, estop is triggered and will not reset.

Even small vibrations or just touching the frame of the machine can trigger SPI errors.

Switching on the hot wire (PWM on SKR, MOSFET) also often causes SPI to fail.

So it looks like any electrical noise or mechanical vibration around the machine is enough to corrupt the SPI frames.

Limitations:

Because I must use the old Remora component for LPC1768, I cannot use the newer SPI options – commands like spi_req or spi_sck_div are reported as “unknown command”. So I currently have no way to slow down or re‑configure the SPI clock from the LinuxCNC side.

Questions:

Is there any recommended hardware wiring for a “noisy” machine with SKR1.4 + RPi to make SPI more robust?

Twisted pairs for SCK/MOSI/MISO/GND?

Shielded cable with shield connected to ground at one end?

Series resistors or small RC filters on SCK/MOSI/MISO / pull‑ups or pull‑downs?

Recommended maximum cable length between RPi and SKR?

With the old LPC1768‑compatible Remora component, is there any way (even a patch or older branch) to:

reduce the SPI clock speed, or

change other SPI timing parameters,
so that communication is less sensitive to noise?

Would you recommend a specific older Remora version (tag/commit) for SKR1.4 that:

still supports LPC1768

but already has the adjustable SPI frequency options?

At the moment the system is “almost working” – jogging and G‑code run fine on the bench – but as soon as the real machine is connected and the hot wire or motors generate some noise, SPI becomes unreliable (Bad payload, estop).

Any advice on:

proven wiring / grounding / shielding between RPi and SKR, or

which Remora version to use and how to tweak SPI timing for LPC1768,

would be very helpful.

Thanks in advance!

Thank you for the reply, but I just flashed at least the 3.3V power regulator with 24V on the still working 7i98 instead, so it will take some time for me to do the repair. Maybe I can even program it using raspberry GPIOs then.
By that coincidence I had an EEPROM with a working firmware, which I just soldered it on the bricked card. Now it works again, but the other one doesn't.

Hi,
i modified the  mesa-smartserial-device-template a little bit
and put it on a cheap ESP32 8ch-Relay board for extra Outputs.

i used platformio as buildsystem for easy use, i have also test the code on raspberry-pico,

github.com/multigcs/SmartSerial-ESP32RelayX8Board/tree/main

www.youtube.com/shorts/6ZKBH5xW8OQ

Relay-Board: www.amazon.de/dp/B0FNRH8QSN

Optional: www.amazon.de/TECNOIOT-Two-Way-Transfer-...tional/dp/B081J5R35N

Works fine with 7i92, but have still problems with 7c81 SmartSerial connector, not shure why,
maybe my pinout is wrong or problems with the TX_en stuff.


my Board with RS422 mod:
 

bin gerade am testen von smartserial auf esp32 und raspberry-pico, so als günstige IO erweiterung.

It shouldn't be the OS it should be the version of Liunxcnc installed.

What happens if you upgrade the version of Linuxcnc on the current install. I only use axis.

Zdavim!
Doesn't seem so(I don't know). Switched from Raspberry PI to PC and Debian 12 Bookworm and I can edit tool offsets no problem.

Edit: Just tried previous version rpi-5-debian-bookworm-6.12.11-arm64-ext4-2025-01-27-0140.img.xz, and editing tools works!

Is it this bug?
github.com/LinuxCNC/linuxcnc/pull/3474