Advanced Search

If you want help, you will have to upload your hal & ini files, otherwise no one knows exactly what you are doing.

Hi Andy... I am muddling my way through this and have things working really well, except inputs. Gpio reads gpio13 fine in python, hal_gpio always shows high in hal scope, meter etc. Any ideas? Is there a way to set gpio characteristics with hal?

I think I've probably been having this problem since I first started using a raspberry pi to drive my mill.  I noticed some CPU-related "hiccups" from the motors early on, and got rid of some background processes that were causing them, and didn't think anything more about it.  But today I noticed some new stutters/hiccups from the motors, and while trying to reproduce, started dragging the Axis window around on the screen.

Well, hoo boy...  the mill sure didn't like that!  Obviously, system load is affecting LinuxCNC in ways that it shouldn't.

So.  I must be doing something wrong, because I assume other people run X11 on their RPi HDMI monitor, and don't have this symptom?

I'm running the RPi 2.9.4 .iso (kernel was built 1/27/2025).

It's driving a Mesa 7i96.  I don't use wireless.  One ethernet is the built-in Pi interface, the other is a reliable USB/Ethernet dongle.  It doesn't matter which drives the Mesa, the symptom remains.

My cmdline.txt looks like this:
Most of that cmdline came from other posts on the forum.

I tried adjusting the IRQ affinity for the Mesa ethernet, to move those interrupts onto core 3 along with the rest of the real-time stuff, but that didn't help.

I'm sure I can find a PC that will work (I did some tests today on an older Thinkpad, with surprisingly good results), but I use the RPi gpio pins to help work around a LinuxCNC shortcoming, and I'd rather not lose that.  I will if I have to, though.

Any ideas, suggestions for things to try?

 

JPeters wrote:

Hello scotta,

thank you for your quick reply. Yes, that is exactly what I thought myself.

The EC500 is powered by an external power supply. From the 6 pin header, GND, SCK and SDO have been connected to one of the probes.

I don´t have any kind of schematic on hands for the EC500. So I am not shure, why the header pin is labeled SDO. I would expect SDIO for a sufficient SWD connector. Is your header labeled with a SDO too?

My EC500 is labeled with IMXR_EC500 2023-05-18

Up to now, there has not been a single successful flash. From within MCUExpresso, I am at least able to build your application.

If this is not going to be successful: do you think, your actual project with W5500 and raspberry pi pico is as powerful as the 1052 solution and could be a viable alternative?

Thank you very much. I will try to give more details tomorrow.

Cheers Julius


 

I'll need to check the labelling on my boards. With MCUExpressoIDE does it report an error when trying to connect. It may give some clues.
Remora supports quite a number of 3D printer boards. The EC300/500 being 24V IO is more suited when using industrial hardware.

There is also an index to this thread located here.
forum.linuxcnc.org/38-general-linuxcnc-q...official-images-only

Read through this thread, there is an example in this very thread.

I have installed the PI5 image (25-01-27) and have gotten everything working EXCEPT the hal_gpio input pins. Outputs...done, inputs... no luck. I can read the input pins with GPIO from python... but not within linuxcnc.

Any ideas?

Hello scotta,

thank you for your quick reply. Yes, that is exactly what I thought myself.

The EC500 is powered by an external power supply. From the 6 pin header, GND, SCK and SDO have been connected to one of the probes.

I don´t have any kind of schematic on hands for the EC500. So I am not shure, why the header pin is labeled SDO. I would expect SDIO for a sufficient SWD connector. Is your header labeled with a SDO too?

My EC500 is labeled with IMXR_EC500 2023-05-18

Up to now, there has not been a single successful flash. From within MCUExpresso, I am at least able to build your application.

If this is not going to be successful: do you think, your actual project with W5500 and raspberry pi pico is as powerful as the 1052 solution and could be a viable alternative?

Thank you very much. I will try to give more details tomorrow.

Cheers Julius

 

Yep and they can be found via using google, probably too many to list. I wouldn't expect a "plug & play" solution going this route.

Before you go this route beware that the software stepping isn't optimal and it may be worth spending some extra dollars on an Mesa card or other such external step\direction control card.

I'm using a Raspberry Pi 4 to drive a Mesa 7i96.   For unknown (as yet) reasons, I can't reliably run without errors unless I bump SERVO_PERIOD to 2000000 (i.e., 2ms).

What affect will this have on machine operation?  I sort of understand what's scheduled to run in the base thread, which of course is largely (completely?) irrelevant now that I have the Mesa.  But I don't have a good mental model for what runs in the servo thread, so I don't have a good understanding of what happens to operation/performance if it only runs half as often as usual.  Where would the difference show up?

Until recently my mill maxed out at about 40ipm, so absolute performance wasn't really a consideration.  I've upgraded to a machine capable of at least 80ipm using Grbl, and initial tests with LinuxCNC and the Mesa card indicate 100ipm may be fine.  So now I'm wondering if I need to start worrying more about that servo thread.

paul

Dear linuxcnc users,
i want to introduce my new open source project based on the W5100S-EVB-PICO . ~10 USD (raspberry pico clone)

features:
1 to 8 step generator with 255KHz maximum output in this version, (possible higher freq) enough for 15m/min with 0.001mm
1 to 8 quadrature encoder counter with 12.5MHz theoretical maximum counting frequency.

current version in the github page is support 4 stepgen and 4 encoders
linuxcnc driver supports multiple instances
planned direct SPI communication with raspberry-pi4 (with normal pico)

github: stepgen-encoder

What about some souped-up Raspberry Pi?

(Max CPU, RAM, etc.)

What voltage does it run on?

You can get very inexpensive DC power supplies from Aliexpress or Digi-Key.

what do you all have against a raspberry pi?
it works well and there are all kinds of cases for it.
2. NIC via USB

Nah my images do work out the box, fark I can actually test them before releasing them in the wild, so far the zram issue has only affected one user. Which whilst I have wanted to put up a new image with the fix there has been push back.
The issue that seems to be with the RPi images is that users think that everything is the same as the images from Raspberry Pi, it's like they can't seperate the board from a particular OS.
The fact that I can run mine with either a 7c81 clone that I've put together myself or a Spartan 6 Dev board with an ethernet interface both running slightly modified hostmot2 firmware proves that it does work. Oh and the RPi platform is younger than the whole Linuxcnc project itself....
But an x86 platform is the best bang for buck, no 2 ways about it. You buy a PC and it's complete ready to go. An RPi5 will need a case, PSU a secondary board to run a NVMe drive or a SATA adaptor board if you want something more spritely than an SD card. The x86 platform is tried and true, it works, it's common, it's rugged and has been used it 54 billion installations by Tommy alone this month, as my estimates go.
The only advantage of the RPi platform is size, tho an Odroid H4 or the older H3 isn't much larger and maybe the SPI interface. The mini HDMI connectors are a pain. In saying that waveshare does do some nice boards that plugin to the existing HDMI, power and audio connectors to bring them out to the same side as the USB & ethernet, a nice NVMe adaptor and a aluminium case to suit.

There is a thread with a guy integrating a cm carrier board with a 7c81.
The RPi5 works but it's a very expensive option compared to an ex corporate PC. The only real advantage is size and that's about it. The RPi5 images work out of the box, but do require the zram fix mentioned in the big thread, it's not a game killer but can raise its head.
Having a RPi5 and 3rd Gen I5 running for testbeds the i5 is definitely the one I'd choose for a build.
For my mill I running a odroid H3 and can not fault it, this has been replaced by the H4.
As for pre-built control boxes, any that rely on the parallel port can be used with a 7i92 for an ethernet option or a 7c81 for SPI with a Raspberry Pi. Some of the issues I have with them is use of DB9 connectors for the Stepper motor connectors. Most of them are quite compact which raises issues of heat and airflow.
I prefer to build my own, lots of room for air flow, the ability to keep the mains and signal wiring well seperated, on side has all the mains, the other side has the low voltage signalling.
I guess if that isn't part of your skill set then an off the shelf control box might be the option if you have the funds.