Advanced Search

Thanks, Andy, you steered me in the right direction.

GPIO13 would not work at all, continuing to research that.

GPIO25, once pullup=GPIO25 was added, works.

I only have 1 limit switch setup, so I'm fully functional with the official image, Byte2Bot board, and my old Probotix motor driver setup.  Attached are the .hal and .ini files that worked, and my config.txt

 

mikereid0817 wrote:

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?
 

You can try setting the various modifiers for GPIO13 and see if that helps.
opendrain
opensource
biasdisable
pulldown
pullup
As described in linuxcnc.org/docs/devel/html/drivers/hal_gpio.html#_usage

I am not clear if you are saying that it is always set and the input can not be changed, even if pulled low?

Have you checked with gpioinfo that nothing is claiming the pin?
 

For the Linuxcnc Raspberry Pi images just don't do dist-upgrade, it will break things, this has been proven.

You get get away without doing any kind of upgrade.

If you are worried about security, updates are only a small part of the picture. The first step should always be physical security, which should be the number one priority with a computer running a cnc machine.I'd take data loss over damage to a cnc machine any day of the week, you can't back up a cnc machine.

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.