Advanced Search

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:)

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.

QtPlasmaC updates - Master (v2.10):

• Fix bugs and enhance Run From Line

QtPlasmaC updates - Master (v2.10):

• do a little less filtering of z moves with keep-z-motion
• fix gcode filter copy/paste error
• fix modifying\creating new materials via magic comments
• add icons for Operator Text and Operator Display dialog boxes

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)