Advanced Search

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:
 

 

Kernel as built following instructions

All my Pi's are 4GB.

Along with my Rpi5 I also have a RPi400, basically the same as a RPi4 with an slightly upped clock speed. I can say I've never come across this issue (even when rod was polishing his iamge utility).
I don't know if this will actually help, but you could try comparing the config.txt files on the Linuxcnc image & the Rasp OS image and see if there is anything that sticks out. This is just a guess.

It might pay to monitor the 3v3 line when booting, both versions, and see if there is anything untoward. Again just another guess.

But yeah it does seem like a confusing issue.

First of all your opening post was great. I'm actaully giving it a go now, just wish I had a nvme drive hooked up to the PCIe bus.
There's a couple of points regarding Linux kernels.

Sometimes the latest kernel may not be the optimum for your hardware.
The kernel you are using is a "release candidate" whilst usable for all intents is still going through some work.
The 6.1.y branch works fine on the RPi4, I think the kernel in the Linuxcnc image maybe 6.1.54
The RPi platforms with regards to Linuxcnc are a little different to the x86 platforms. Your Rpi4 & Rpi5 hardware is what it is. Whereas you may need a specific kernel dpending which x86 motherboard you buy.
The Rpi branch that appears to be active is the 6.6.y branch, so one could assume this is the branch that is receiving the most "bug fixies".
Simple things like isolating cores 2,3 will see latency drop. There doesn't seem to be as many options/tricks for latency on the RPi platforms as the x86 platforms.
I would chose to use a kernel that is a couple of version behind the the latest and greatest if it more tried in the real world and has better latency.
In my discussions with royka we talked about the fact that a kernel that is a little older is sometimes the better option.
Due to the issues with wayland I would recommend the use of the image form the Download page, Xorg is used. Plus it's easier to deploy

Mind tho I'm not saying this is the only way to do it.
What I would suggest is trying some of the earlier kernels to see how performance differs.

One thing regarding the 6.6.y branch.
The latest version is 6.6.70 which I couldn't find any real time patches for.
The previous commit is 6.6.65 for which there are rt patches, but for some reason the overlay's aren't in the source. Which is a pain when building an image using Rod's image builder.

It seems, ATM, the deeper you dive it can seem a little confusing.

Sorry for the multiple posts but this editor is PITA.

In a Debian environment tasksel allows you to install a number of desktops. There is a (X) reason why we use XFCE in the linuxcnc images. It uses X windows not wayland

I can guarantee it's not bricked. I loaded the raspberry Pi OS onto it after that with no problem and was able to access it via SSH to download data from the Pi library. I tried 2.93 as well and got a similar result only this time there were some penguins at the top of the screen instead of skulls  

Just updated the bootloader and tried again. Got a similar result but now the ACT LED is flashing consistently instead of barely visible. 

I'm surprised nobody else is experiencing this. Am I the only 8G user to try these? Do I need to have some additional board attached for it to boot properly?

[Edit, after hearing it might be bricked, I tried the same card on a 4gig Pi4B that I've been using perfectly fine for years with the same result] 

It would be interesting to see the latency values after switching to X. This can be done via the config utility for the Rpi, the actual binary name escapes me ATM.

Thanks for the heads up regarding wayland and axis.

If you're using a Rasp OS image you'll want to swap from wayland to X if you are looking to run axis, the "compatibility layer" is "not quite optimum".