Advanced Search

It's not that you are missing files but that your hal files content doesn't harmonize:

If you are unsure you can just comment out the line in your gmoccapy_postgui.hal and any others that may throw errors so you can start your config and see what is missing.

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!

Naja genauer kann ich es nicht beschreiben. Ich habe ein neues Setup gemacht,wo ich den Referenzpunkt fürs Bohrfräsen auf die erste Bohrung gelegt habe ,wir werden sehen,ob es jetzt Funktioniert.  Hab es jetzt Getestet !  Zuerst mit dem Fräser 1mm tief in die 8mm Bohrung Eingetaucht zur Kontrolle,stimmt der Fräser fährt genau ins Zentrum der 8mm Bohrung,will aber dann genauso wie vorher 10mm in X Versetzt Fräsen... Ratlos !

I am quite proficient with build-install-clone commands and have the ability to simultaneously have and use all the versions under investigation on a single HDD. Currently installed and used alternately are
2.8.4 and 4.19. 195-rtai-amd64 - works almost flawlessly, except for a known (and already fixed in 2.9.7) bug (I easily ported it to 2.9.4, as well as matrixkin from 2.10 to 2.9.7 and 2.9.4), so I have to do without G38.5
2.9.4 with kernels 254 and 290 - they are unable to work due to a bug for multi-engine configurations, see forum.linuxcnc.org/9-installing-linuxcnc...-2-9?start=60#339123
2.9.7 - of course, I don't like userspace, but I am ready to use it for G38 tasks. It is unable to work due to this, forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#338958, bug

What would be really useful (including to me) would be a flowchart that tracks a simple G-code command (like coolant-flood) from the Interpreter to the HAL pin.
There are so many layers and abstractions (not all of which seem necessary)
Oh, and a clear indication where the switch to realtime happens in this flow would be helpful too.

Yes, the biggest hurdle when working on an issue is figuring out which parts of the source code are involved in the first place. I have used Sourcetrail and Doxigen but what I really lack is a bigger picture.
- what happens in case of a program abort
- what is involved when the feed override value changes
....
That probably is the greatest loss when a long term contributor retires from the project.
Documentation of such trans code 'paths' would also likely be less prone to become outdated as the source code evolves.

Its very difficult to deal with a 4.0 metre long page if you want a hard copy (which is the whole point of PDF). What printer does that? The page width of 210mm is the exact width of an A4 page. Is there any chance you could add page breaks  say every 297mm (you may need to allow for page margins too which is all supported in PDF.

MTTI wrote:

I’m not a programmer (only a bit of Python, and some BASIC and C). It took me the whole day to find this issue, moving a debug print line around the code to locate where it was getting stuck.Thank you for the explanations, and also for pointing out the second copy/paste bug, I’ve fixed that one on my side as well.

Now I need to follow up with Pronest, as the post-processor still doesn’t insert commas between the parameters...

Regards

Me either to be honest. I do this because it differs from my day job, gives me something new to continually learn, and because I enjoy it.

I appreciate your collaboration!

Andy, just found your orient.svg  which has encouraged me to have another go. Especially as I realise the function could be useful when probing.
Thanks for your clarification.

Is the grayscale encoder aligned to the carousel (ie, it corresponds 1:1 with the tool pockets) or is this an encoder on the motor?

The "gray" mode of the carousel comp is intended for the former case.

If it's a motor-mounted encoder look at using "counts" mode. (with an encoder counter that is scaled to the pocket spacing)

Segfaults are typically problems with the linuxCNC software writing out-of-bounds.
Are you running any custom HAL modules?
Which HAL components are in-use?

Sorry, but RTAI support has been a bit lax lately, though I am still committed to it at least in 2.9.

What would be really useful (including to me) would be a flowchart that tracks a simple G-code command (like coolant-flood) from the Interpreter to the HAL pin.
There are so many layers and abstractions (not all of which seem necessary)
Oh, and a clear indication where the switch to realtime happens in this flow would be helpful too.

I don't know why 2.9.3 was removed either,[1] but 2.9.7 should be better. (basically just the same, but with bugfixes)
And if you have previously down;oaded the 2.9.3 image, don't you still have it somewhere?

[1] And it's almost certainly me who did it

If you need an RTAI version of 2.9.7 I will try to build one.

But given your reported issues elsewhere it might be worth setting-up to build from source. It's not especially difficult, though there is a oe-time investment in installing all the build dependencies.

Get the basic tools:
Then get the LinuxCNC source code:
Then enter the source directory and switch to the 2.9 branch
Now you are going to need a whole bunch of packages, dpkg knows what you need: (you need to be in the linuxcnc-dev folder , where you can see the debian folder)
The only complication here is that the build will be a run-in-place (can exist alongside a standard install) and to chose it you need to run a script.(Yes, it really is dot-space at the beginning)

I now have reliable switching between spindle mode (PV) and C-axis mode (CSP).
The key issue was not the controlword itself, but the fact that the commanded and actual position of the drive did not match at the moment of switching.To fix this, I’m using a small custom HAL component (c_pos_sync).
While in spindle/PV mode it continuously feeds the C-axis command position with the actual position (a “follow” mode).
When switching to C-axis mode, this offset is preserved — so there is no position jump and no mode-fluttering anymore.With this in place:

• M3/M4 work normally in PV mode
• M5 stops correctly
• M64/M65 switch to C-axis mode without instability
• G0/G1 C… moves work as expected
• Switching back to spindle mode is also stable

The zero-speed bit from the statusword is now used only for diagnostics, not as a gating condition for switching — this was the original cause of the Mode 3 ↔ Mode 8 oscillation.M19 is not fully tuned yet (separate topic), but it no longer affects the mode switching.I’ll attach the HAL file and the small sync component in the thread.