I am sending you the corrected custom.hal file; I believe I had sent you one with some errors.

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!

Why would you be attempting to offer a LPT card in this instance ?

I tried what you suggested, it doesn’t work, it has erratic behavior. It performs poorly in 2.8, 2.94, and 2.97, it behaves erratically in all of them, I don’t understand what’s going on

Now it's morning time I'll have a look into this in a couple of hours.
Note to self, you're too old for late nights.

I don't have such a setup so it is very difficult to say.
But it sounds like the current position is lost, and when you go back to csp mode the current position is set to zero no matter how the spindle actually is rotated.
aDm1N had something about tracking position didn't he? Did you try that?

Thank you Hakan.

This was very helpful. With your cia402pv and the files from aDm1N, I managed to get the servo running with GCode Commands both for rotation and positioning.

Here are the things I had to change in the hal-file:
- net c-mode-request and2.3.in0 -> spindle-ok-for-c
- net spindle-speed-normal spindle.0.speed-out mux2.0.in0 -> spindle.0.speed-out-rps
- and of corse some names and scale values

Now to my problem:
As long as I only use G0 and G1, the servo positions correct (example: C0 is at 12 o'clock). Then I let it run with M3 S1000 and after a while I stop it using M5. Now the servo stops at its position. In my optinion it should move to 12 o'clock, if I use G0 C0. But nothing happens. If I type G0 C90, it moves 1/4 revolution. So it looks like if the stopping of the servo sets somehow the zero position? 

video     That's what I did when I ran into the problem

2.9.7 I can't manage to start a configuration with inverted output ports.

pin 1-14-17 out-inverter-1 seems not to work

I can change state, but I can't start a setup with an inverted state

Unfortunately, in trixie image_2025-11-10-raspios-lcnc-2.9.7-6-trixie-arm64.zip the command mesaflash --device 7c81 --addr /dev/spidev0.0 --spi --readhmid doesn't work. No 7c81 board found.

Danke. Werde ich mal ausprobieren.
Gruß Andreas

understood, thank you.
I will look for tutorials as i'm beginner with this technology

Not sure exactly how that works. TIM2 and TIM5 share things, at least encoder pins, so only one encoder.
Maybe there can be TIM2 on one pin and TIM5 on the other for other purposes, not sure.
You can always do some surgery. Prototype in free-run mode and you don't need sync0 and sync1 which are
on TIM2 CH1 and CH2, so you can free them up and use them for encoder input for the 32-bit encoder.
Solder on tiny wires and melting glue. Has happened before.