Advanced Search

Hi all, 
after swapping our Raspberry Pi4 with a 5 things didn't work anymore as they did before, and thanks to this forum, as far as I understood there is no SPI support yet, right? 
I have also read that "rodw" you have created an image builder, and "Cornholio" you managed to patch it so it works right?
As we are trying to run the mesa 7c80 with a Raspberry Pi5, is there an image available currently that supports this combination? If not what would be the steps to "patch" it together? 

Thanks a lot in advance 

With the 5A-75B and 5A-75E we have a low cost way of creating a driver board for Linux-CNC. Based on the work of Romanetz, the project  LiteX-CNC  was started, providing a easy customizable firmware and driver to use these boards. The down-side however is that these boards require some soldering work to be done to accept inputs; I've messed up some boards in the process....

Therefore, Litex-CNC is going to be expanded to accept more FPGA's, starting with the Sipeed Tang Nano 20k. Compared with the 5A-75B it has less outputs (28 compared to 48 for the 5A-75B), but this is still enough for a simple 3 axis machine. The big advantage is that no SMT soldering skills are required to get this board up and running.

For the Raspberry-Pi I've designed a HAT, which provides:

• 7 extended PMOD-connectors. Each connector has 4 GPIO, power rails (+5V, max 200 mA) and a buffered enable signal;
• RS489 connector for communicating with for example a VFD;
• communication between Raspberry PI and FPGA using SPI in bidirectional mode (3-wire) to save on pins;
• conforms to the HAT+ specification , including a EEPROM with settings.

With the PMOD-connectors one can easily connect to break-out boards providing stepgen, GPIO (12V/24V inputs and outputs), differential encoders, etc. I'm also working to provide support for shifting data out (74HC595) and in (74HC165).

An estimation of the HAT will be around 7 Euro's, excluding the Tang Nano 20k. Inlcuding the FPGA, the price would be around the 40 Euro price point.

I am new to LinuxCNC, so please forgive me if this has already been answered.  I searched and could not find it anywhere so am asking here.  (I always hate on other forums when people just jump in with questions before searching.)

I have a 7i92TH connected to a Raspberry Pi 5.  The use case for it is for rose engine lathes, and we need to drive a spindle + 7 axes.

The break-out board we are using for both 26-pin outputs from the 7i92TH was developed using the input from Peter.  Fundamentally, we will have

• 8 outputs to drivers, all with Step, Direction, & Enable
• 7+ inputs for limit switches

Peter W. got us setup with the files needed to program the 7i92TH, and that seems to be working as expected.  When I run

         mesaflash --device 7i92t --addr 192.168.1.121 --readhmid

the output matches the .pin file supplied by Peter, telling me that the mesaflash --write command worked to load the .bin file supplied by Peter.

When running pncconf:

• I've tried with copying the contents of the .pin file into the Input tab on the Help screen, and not doing this.
• I was able to successfully discover the 7i92TH board, and it populated the Output tab on the Help screen (I didn't check word-for-word, but it seems to be duplicate of the output from mesaflash --readhmid).

When I want to proceed forward, assigning the pins to axes, I encounter the screens I've attached.

ISSUE for which I'm seeking help:  I can't figure out how the Num items (pin numbers?) match up to the .pin file.  What am I missing?

Rather than starting a new thread about jitter mitigation, I'm just going to add it here.

First, I'm keeping in mind that Peter Wallace said " The jitter is basically unimportant with a 7C81 unless its so bad you
get real time errors at the normal servo thread rate ."

I'm also treating the Raspberry Pi + 7C81 as a dedicated controller, not a PC. By that I mean I'm not going to be doing anything on the Pi except LinuxCNC. I may turn on WIFI to update packages, or use email to transfer a file. But I plan to even turn off WIFI before I launch LinuxCNC.


I ran several tests to see which combination of settings offered the most optimized jitter. I ran two Glxgears for all tests as I though that was reasonable, and ran the tests for long periods of time unless they looked bad early on.

I thought that turning off all unused services would decrease Jitter. So I turned off 9 of the 23 services, such as CUPS, Bluetooth, etc. To my surprise this did not decrease jitter.

Screen blank increased jitter a bit, so I turned that off. It doesn't make much sense anyway on a CNC controller.


These are the settings I added to the line already in /boot/firmware/cmdline.txt:
I tried a few others that some people recommended on various blogs. Nothing else I tried had any noticeable positive impact on jitter, and some noticeably slowed down the responsiveness of the Pi.


Turning off timer_migration did reduce jitter. What I read said that you could make this setting permanent by adding it to the boot command line, or setting it in either of two different system files. Oddly none of that worked. So I setup a cron job to disable it at boot, and that works.Add the following line:

The other thing that helped reduce jitter was changing the scheduling policy to real-time and increasing the priority. I decided to create a shell script to launch latency-histogram, and eventually linuxcnc, which changes these things on the process.
I named it rrt (run real-time). So to launch latency-histogram it's simply:
All spawned sub-processes inherit the policy and priority. So if linuxcnc is launched with rrt:all of the processes that are part of LinuxCNC have the policy of SCHED_RR and priority of 99. I used Round Robin scheduling to make sure no LinuxCNC process "starves" another.

I don't know if this will work in the end, but I'm going to give it a try. Nothing ventured, nothing gained.

Implementing all of these, here is the jitter histogram. Good enough.

 

Ah yes the editor. Truly you have come of age and walked the path of darkness

I edited my original post to include changing the display protocol from Wayland to X11. Comments by rodw and cornholio were based on the terrible jitter that Wayland induces as shown above.

Note that Kunena has the worst forum editor I've ever used, and it was quite a job to edit those posts and restore the formatting. I wonder if forum posting would increase with forum software that was more user friendly.

Looks a lot better.

One thing that was strange when running a basic config I got a real time error. hmmmmm

ATM the best image I've come across is Joco's rpi5 image rod has on his googledrive, that has a 6.6.54 kernel. It's my choice of the pre-built images.

I installed mate desktop, with 2 cores isolated, watching youtube latency is about 17-18us on my pi.

The good news is switching to X11 is trivial.

You can check the session type:    wayland

Launch Rasp-config command line tool in a terminal:
Arrow down to "Advanced Options", and enter.
Arrow down to "Wayland                 Switch between X and Wayland backends", and enter.
If not on the line that says "W1 X11     Openbox window manager with X11 backend", arrow to it and enter.
The popup should say "Openbox on X11 is active" and have "Ok" highlighted. Enter.
It will return to the main screen. Use left-righ arrows to select "Finish". Enter.
Popup asks if you would like to reboot now, with "Yes" highlighted. Enter.

After reboot:    x11

Now here's the interesting apples to apples comparison. The only difference between these two pre-jitter-optimization baseline latency runs is Wayland vs X11.

Wayland:
 

X11: