Advanced Search

Thanks Tommy for picking up the slack in my less than ideal state of alertness.

One thing I would like the OP to confirm, is when using halcmd do you get proper comms with the board ? Just to confirm we aren't dealing with a hardware issue.

Once again I apologise for my lack of alertness.

I know that with the mesa 7c81 boards it is recommended to have a length of less than ~2.5" for the SPI cable length. So it just maybe the cable length is too long.
Dupont cables aren't ideal for SPI transmission at speed.
So ideas to try.
Ribbon cable with every second conductor a ground terminated at one end only, of course you will need a dedicated return ground. This may involved a custom bit of PCB at each end.
Shorter cable length for sure.
There's some other fixes I was going to suggest, but since the remora bards are "all in one" they would not apply.
But I guess a quality PSU, think Meanwell, might be worth considering.
My first port of call would be to reduce the SPI cable to the absolute minimum, preferably to under 2.5" max.
One thing of note is that I have the RPi5 can tolerate a longer SPI cable that the RPi4, the caveat being this is based on experience with a home made 7c81 clone.
I'm apologise if the references to the 7c81 is annoying, but it is entirely based on my experience with SPI as a communication medium. I honestly hope that some of the above suggestions will give you good for thought.

  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? 

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

"out-inverter-1" should be: "pin-01-out-invert" (in the title)

Try setting pin-01-out-invert to 0 instead of 1.

Perhaps 1 is the default value.

Check all the HAL files in case the stuff in another file is messing stuff up.

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

Weird.

Try creating a new config with StepConf and look at the HAL file(s) it generates or look at the hal file(s) in an example config to make sure your syntax is correct.

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.