Just received the other email, (didn't make the connection to you)
I'll try as you suggested, nothing to loose at this point.
Thanks so much for the help
M

Ok. got it to work with the intel itx board. the fujistu minipc is hopeless.
I got it with 7i92_G540x2D firmware, kind of weird to setup the pins. Is there a simple firmware?
For reference i'm planning to use an lathe like 400x1000 3 tons with live tooling so no Y axis (X axis, Z axis and C-axis)

Edit: BTW i used a chinese usb stick (USB 3.0) and when i install the linuxcnc it gave errors (like the password for the wifi did not work or it refuse to install grub loader, so i use another usb and it works like charm).

As I mentioned in our email communications, the 3.3V power supply may be shorted out
by the damaged chip (there may be more than one unfortunately). So if that is cleared,
communications may work. Also as I mentioned, damage to the I/O section of the 7I84U
is unlikely to propagate to the serial interface side as that is galvanically isolated (2KV!)
from the I/O side.

You might check if there is 3.3V (measure from W1 pin 1 to 3, pin 1 should ++3.3V)
Lack  of 3.3V may mean damaged 3.3V regulator or shorted part.

M
 

Nothing like that around me. The LV4051A chip closest to that area of the board has a bulged up spot in the middle and it's a multiplexer so it's probably toast but since there's no sign of any connection between the two boards now it must have taken out more upstream of that. I'm just hoping it didn't kill the communication part on the 7i06s
M

You might check if there is 3.3V (measure from W1 pin 1 to 3, pin 1 should ++3.3V)
Lack  of 3.3V may mean damaged 3.3V regulator or shorted part.

There is an experimental version of pncconf (for LinuxCNC 2.10 only) that supports the 7I97T in this thread:

forum.linuxcnc.org/plasmac/55286-servo-d...ofit?start=10#331289

Note that there is no specific firmware needed to support the 7I73

There's also a sample 7I97T configuration to which  7I73 support could be added:

 


To list 7i73 pin and parameter names:

halcmd show all | grep 7i73


while LinuxCNC is running


 

Do you have a thermal imaging or infrared camera or do you know someone who has one? Defective ICs often get hot when you apply power to them.

Just chiming in that I purchased a similar amazon 4th axis and had the same issue and fixed it with this. This reply just serves as a personal bookmark for me.

I have been trying to get my 7i97T to work with a 7i73 so I can use an MPG and a few other local input buttons. I've tried Mesa CT but it will not work with the 7i73, no option to flash that card. So I tried Pncconf and it does not build a good file for the 7i97T. I tried the board discover option and it appears to work but when i actually try to launch the build file it give me a bunch of errors on the 7i73. If I change the I/O of the error pin to not used it just errors out on the next pin... Another issue that is also related and why I'm attempting to use the Pncconf is that I need to install a tool setter and touch probe. Pncconf would be the way to go but i cant get it to work with me. Has any one run into this before?  

We making progress but looks like I smoked the 7i84u.

One of the wires from a set of prox sensors, PNP NC, came out of the terminal and touched the board and now I've lost communication between the 7i96s and the 7i84u.
It powers on, CR2 and CR7 light up green but the red CR5 never comes on at all and there is no activity on CR6.
The card doesn't show in the HALmeter (I'm pretty sure I had it under the pins section when I was testing these sensors)

As far as I can tell the 7i96s seems fine, I'm hooking up some steppers to test and make sure

Anyone know if there is there anything I can test here? Not sure if it's worth sending back for repair or just buying a new one (i'm in canada, not going to be cheap to send for repair)

M

I will try today the potentiometers for feed and spindle, I noticed when I opened the panel that this is not ``mpg'' but the same potentiometer:)..its power supply is connected to the power supply of the potentiometer for feed and speed and its mass is connected to the physical buttons jog+ and jog-..it probably had some logic in the plc of the old controller, I will have to replace it with a class mpg of 100ppr it seems:)

Re: the above, could somebody show me what the folder structure and contents should look like in a functioning gmoccapy lathe installation please?

I want to identify the files that are missing from my system that are preventing it from working.

Many thanks.

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!