Advanced Search

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

I don't know if it belongs to here, but after fresh install Raspberry Pi 4/5 OS based on Debian Trixie, and initial setup I'm not able change tool offsets at all. Also work offset changes are displayed only after clicking off and back on "work offsets" page.

Habe meine Mesakarten vorgestern erhalten, gestern getestet. Sowohl die 7i92, als auch die 7i98 funktionieren einwandfrei mit originaler Mesa Firmware. Auch die Busschalter funktionieren so, wie sie sollen (inkl. Pegelwandlerfunktion). Die Widerstände an den Pins sind externe pull-up Widerstände.
 

Bei der 7i92 ist es wichtig, die richtige ZIP-Datei herunterzuladen (für die 7i92H oder 7i92TH). 7i92t.zip lässt sich nicht flashen.
Wichtig zu wissen ist, dass der Fallback-Jumper nicht funktioniert.

Falls die Karte vom Raspberry nicht erkannt wird, muss man zuerst die Verbindung über die Konsole herstellen:

sudo ip addr add 10.10.10.11/8 dev eth0
sudo ip link set eth0 up

Ich bin mit dem Kauf jedenfalls so zufrieden, dass ich eine weitere 7i98 bestellt habe, diesmal in 7i92-Größe: de.aliexpress.com/item/1005010164826951.html

unknown,

Do you have a Debian Trixie version with RT-PREEMPT kernel for a RaspberryPi 3B+?
It is everywhere written that Trixie already is ' real-time', but I faced a lot of issues when trying to run LinuxCNC on Trixie. Especially on a RaspberryPi 3B+.

Regards, DGdodo

My SetupRaspberry Pi 5 8GBByte2Bot Parallel Port Raspberry Pi HatByte2Bot 5 Axis CNC Interface Adapter Parallel Breakout Board For Stepper Motor DriversPicture 1My wiring is as follows:Picture2

The motors move, the home switches register as functioning, the probe is not hooked up and the eStop appears to do nothing.From LinuxCNC V2.9.7 Documentation PDF Page 1854.9.3.7 External ESTOP button The standard_pinout.hal file assumes no external ESTOP button. For more information on an external E-Stop see the estop_latch man page.Yet from 2 pages earlier in LinuxCNC V2.9.7 Documentation PDF Page 183 I see this line in the HAL file:# create a signal for the estop loopbacknet estop-loop iocontrol.0.user-enable-out iocontrol.0.emc-enable-in I assume “man page” is a typo and this is unnecessary if I am trying to connect it to  GPIO25. A search of the document looking for “estop_latch” only reveals this on page 254Picture 3So my estop is on pin10, but that is GPIO25 on the Pi 5. I must refer to it as such.In my .Hal file I have the following lines:loadrt hal_gpio inputs=GPIO7,GPIO8,GPIO25,GPIO12,GPIO13 outputs=GPIO5,GPIO6,GPIO11,GPIO9,GPIO10,GPIO23,GPIO16,GPIO17,GPIO19,GPIO20,GPIO21,GPIO22,GPIO24,GPIO26net estop-out   <= hal_gpio.GPIO25-in  ornet estop-ext <= hal_gpio.GPIO25-in Using tools I can identify that all my limit switches are being read, but I have nothing to suggest the estop is being read.I have added“Addf gpio-input servo-thread” as recommended by ChatGPT, and that is not read by the programThe advice I am looking for is:
I would like to know how to connect GPIO25 to LinuxCNC’s E-Stop chain.I have tried:

net estop-out hal_GPIO.GPIO25.out => iocontrol.0.emc-enable-inand any variation thereof I could think of, failed.Eventually, I lost control of my servos and only when I removed all lines I gained control of F1, which controls the estop and F2, which powers the servos. 

So, it doesn't work.

To begin with, we had to solve the problems of inaccuracy of the installation description instructions. The downloaded attribute immediately after installation shows us v2.9.7 userspace. In order to install 2.9.2 rt you had to -

1. Overcome the distribution configuration error by removing the file stub for the raspberry -
forum.linuxcnc.org/38-general-linuxcnc-q...d-apt-problem#332403
sudo rm /etc/{initramfs/post-update.d/,kernel/{postinst.d/,postrm.d/}}z50-raspi-firmware

2.then you need to fix the first line of the file by adding 2.9-rt to its end
vi /etc/apt/sources.list.d/linuxcnc-uspace.list
deb [arch=amd64,arm64 signed-by=/etc/apt/trusted.gpg.d/linuxcnc.gpg.key.binary.gpg] www.linuxcnc.org/ bookworm base 2.9-uspace 2.9-rt

3. then you need to completely remove version 2.9.7
forum.linuxcnc.org/9-installing-linuxcnc...tall-rtai-got-errors
-
apt-get purge linuxcnc-uspace
apt-get purge linuxcnc-doc*

4. then you need to put the kernel (and only the kernel!)
wget www.linuxcnc.org/dists/bookworm/base/bin...ai-amd64-2_amd64.deb
dpkg -i linux-image-5.4.258-rtai-amd64_5.4.258-rtai-amd64-2_amd64.deb

5. This new kernel will now appear in boot options, you need to reboot the computer by selecting this particular kernel 5. And only now supply additional components -
wget www.linuxcnc.org/dists/bookworm/base/bin...xcnc-delta_amd64.deb
dpkg -i rtai-modules-5.4.258_5.3.3-linuxcnc-delta_amd64.deb

Now you can apt-get update + apt-get update

A running real-time kernel will always show 100% CPU load and does not need a swap. latensy-test starts and shows normal numbers.

An attempt to start the existing machine configuration leads to a system crash and reboot. Okay, stepconf and I create a new configuration, extremely simple. I launch it and also get a reboot.

Debug file information:
/usr/bin/linuxcnc: line 977:913 Segmentation error $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
/usr/bin/milltask exiting

How to overcome this problem?
A discussion of the problem has been initiated here, but there is no solution
forum.linuxcnc.org/18-computer/51070-fro...-kernel-rtai-5-4-258

Stepconf is only for PC parallel ports.
Byte2Bot Parallel Port Raspberry Pi Hat is not an actual Parallel Port, yes it is confusing and probably somewhat misleading the way the Vendor names it. It does not provide any of the logical functions of a PC Parallel Port only presents the pins in a DB25 format and provides some level shifting.

The 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

The reason for these 2 threads was to provide users with a "self service and all in one stop".

Hello. I am a new user. I've been at this for days and no joy. I just came to the realization that StepConf Wizard does not work on my setup. Here is my logic. 
I have a Raspberry Pi 5 with a :
Byte2Bot Parallel Port Raspberry Pi Hat                  byte2bot.com/products/parallel-port-raspberry-pi-hat
5 Axis CNC Interface Adapter Parallel Breakout Board For Stepper Motor Drivers      byte2bot.com/products/5-axis-cnc-interfa...tepper-motor-drivers.

I am running Linux Bookworm with an installation of LinuxCNC. 

When I run StepConf Wizard and get to the X-Axis page I attempt ot see if I can move that axis - no joy. 

My theory is that it doesn't work. I feel that when I complete the process for a machine which I will call Machine, I end up with a Machine.hal program that has lines containing "hal_gpio.PIN21-out" or "hal_gpio.PIN12-out".

Using the Byte2Bot parallel port, you are NOT allowed to refer to the output on the DB25 connector as PIN1, PIN2, PIN3 etc. Using a Byte2Bot hat with a Raspberry Pi 5, you must refer to the GPIO pin that is connected to PIN2 or PIN3 as it's corresponding GPIO pin on the Raspberry Pi. As an example, PIN2 is actually GPIO9, so the line would have to be "hal_gpio.GPIO9-out" to activate PIN2. 

Seeing how StepConf Wizard is asking me what feature I want to assign to PIN2, I assume it is passing on the command ""hal_gpio.PIN2-out" which doesn't work, rather than "hal_gpio.GPIO9-out" which is required. 

I have noticed that you can pick different interfaces prior to getting to the Axis X page, and the assignments change, BUT there is no corresponding change for the Byte2Bot setup.

I might also point out that I have found examples that PIN2 etc. that reportedly works on the Pi 4  

Having made my case I suspect that I will hear "We can't set it up for every possibility" but I think I am missing something. 

EdWorks