Linux beginner RPI 5, GPIO + ethercat 4 axis adventure

Hello all, 
In this thread i intend to to document my attempt to to build a controller for a 4 axis mill, from concept to implementation. 

I am highly inexperienced with Linux and programming in general,  so this may be new source of entertainment for the more experienced members. The hope is to leave a trail someone as daft as me could follow, to create a workable controller.

The Photo's of screens and other dubious content is aimed at providing a quick and dirty temporary reference for those of us who don't know what the result is supposed to look like, if this ends up being of use i will tidy it up.  


The end goal  is a 4 axis ethercat motion control system with RPI gpio performing a few less timing sensitive functions such as spindle direction and gear selection.  with closed loop position control.



 

Welcome and feel free to ask/teach/entertain us.

So one of the first questions that seems to crop up is latency/jitter and general performance of the RPI5 vs PC hardware and older RPI models.
 
I don't have an old pc available but i do have a RPI 4b and a PRI 5, both with 8gb of ram. and i can test the RPI 5 with and without the PCIE NVME hat to see if that makes any meaningful difference.
For fun i might try a usb bootable image for the laptop i used for Mach4 and Ethernet Smooth Stepper.

All will be tested with Linux CNC 2.9.2, SD card tests are done with a fresh image from the RPI Imager using the same sd card. 

For the NVME test  i have been playing with that install(2.9.2) for a few days (and the jitter looks worse for it I think).

All tests done with 10x glx gears running and Linux CNC guide open in firefox and scrolled around to get some idea of loaded up performance. 

All RPI tests will be also using the same keyboard, mouse and HDMI + USB touch screen 

As a side note the NVME drive seems to make the PI5 feel more responsive and quicker to bootup. 

The performance of the PI4 with a desktop is new to me as i have only used it headless to run a 3d printer with klipper.  

Well i have some results, but I'm not sure what they mean in real terms beyond the recomendations in the documentation. I would be curious to know how they compare to other peoples results.  

DUT                       base thread  (us)                  servo thread (us)

RPI 4b sd card       -24.7 (sdev2.5) +79.1        -149.2 (sdev5.4) +148.6
RPI 5   sd card       -23.6 (sdev 1.0) +19.3         -30.6  (sdev2.1) +31.6
RPI 5   NVME         -13.1 (sdev0.9) +12.1          -15.7 (sdev2.1) +16.3



 
(left running for 7 hours, result above unchanged)

Going by  linuxcnc.org/docs/stable/html/install/latency-test.html   the sub 15 microsecond base jitter provided by the RPI 5 with NVME should allow software stepping and the hardware seems capable from this crude test.. And yes i did take a photo of the screen because i am a luddite.
 

Your latency looks fine for ethercat. To me it does not make sense to adopt ethercat and use another system for I/O. Use a ethercat I/O module

Good point, Rodw.

Part of my interest in the GPIO was to use encoders for screw mapping or closed loop control, thinking the more ethercat components i buy(controller budget) the less the retrofit budget for the mill.

However a serious deficiency in motion control cannot be compensated for in motion hardware and vise versa. 

I now have an Ethercat IO module next to me (arrived this morning along with some cat 6e patch leads) but due to me being a clown it seams the connection module for the ethernet cables is a discreet entity, and that will arrive tomorrow along with a 2x channel encoder interface.

On rout from china is an Rtelegent ECT60 Ethercat closed loop stepper driver that should be compatable with the 4x nema 34ish encoder equipped steppers i removed from my first cnc retrofit project. If i can bully them into working together i will order 3 more. 

As for the Ethercat IO and encoder inputs i have aquired some Beckhoff modules.

EK1100 Ethercat coupler  (don't forget this bit )
EL2609 18x 24v digital output 
and possibly the wrong encoder interface for TTL grrrr