Advanced Search

Ok the screenshots are interesting. Unfortunately I haven't had a chance to check as life has got in the way.
To tell the truth when I test the images I use an old 19" 4:3 monitor. Another thing to be aware of is that the images aren't meant to be for a daily driver, the sole purpose is to run Linuxcnc which is what is concentrated on. So yes there will be packages left out that are part of a standard Desktop install.
The kernel was built using the official RPi sources, with the only mod being enabling the RT section in the kernel config. So there is really nothing fancy in that area.
It very well be an issue related to resolution, in config.txt you should be able to adjust the memory allocated to the graphics system, something you'll have to look at the config.txt documentation, 2 things to be aware of, there is no raspi-config utility so the config.txt will need to be hand edited and the location of it is different to the Raspberry OS, the main thread for the images has this info.
If you just want to explore what Linuxcnc has to offer without running a machine or connecting to any hardware there is also the option of running the amd64 version as a live session on a PC or installing in a virtual machine such as VirtualBox. RT capabilities will be non existent but it will run the simulations fine.
Another option would be to install RaspiOS and build Linuxcnc from source, a real time kernel would not be required in your case and use at ad a Run In Place install. How to do this can be found in the docs.

Thanks for the replies. I finally got a chance to check out the suggestions on the RPi400. For testing I made a new fresh image on a new SD card, and the graphical glitches could be reproduced, but it may be just an issue in chromium browser, which is not installed by default. I did not reproduce the issue in Firefox, and though it is painfully slow to load pages, Youtube does play... eventually.

The SD cards used are 64GB Kingston Canvas Select Plus. Nothing fancy, but I doubt it is the issue, since I've used multiple, and other images (default RPi OS, Ubuntu 24.04) don't have the same issue.

For reference, here are some screenshots of the glitches in chromium. Btw, I had to install xfce4-screenshooter to be able to take screenshots, as it is not installed by default in the LinuxCNC rpi image.

The first screenshot shows a horizontal section of the web page with corrupted graphics. The second is chromium's setting page which never displays correctly. The third is a pdf document opened in chromium, with the controls (download, zoom, etc) at the top not showing. The fourth shows the graphical glitches in the Youtube player controls (buttons for play, pause, settings, etc).

They work in Firefox (very slow though, which is why I installed chromium) so perhaps this is not an issue specifically with LinuxCNC's image, though I can't tell. I don't have these issues with chromium on the other RPi OS images, but I have not tried debian 12 directly. I imagine that also precludes hardware issues. The monitor is a 22" Dell at 1680x1050, though I doubt that is too relevant.

Aside from isolcpu, were there other optimizations made which may impact graphical or general performance?
 

this waveshare thing working fine with vivado:
www.amazon.de/dp/B00KM70UFG?ref=ppx_yo2ov_dt_b_fed_asin_title

if you only need to load the bitfile, you can use the installed linux-system.

i know that someone in this forum has running linuxcnc on an raspberry-zero 2 with sdl gui,
this is not so fare away from this cores.

## I actually like vivado. wouldn't it be nice to have cnc modules (step gens, counters, pwm etc) set as ip blocks in vivado so it can be just visual drug and drop to create configuration you need. File Attachment:

hmmm, maybe we can convert some rio plugins into vivado blocks
at the moment the complete rio part is shown as one block in vivado.

Hello,
I just joined the forum since I'm making good progress with my PRINTNC project. I want to use 4 closed loop step motors (2 steppers for z axis). I keep look around but everyone is using a MESA boards or a raspberry pis with some kind of adapter boards for connecting the stepper drivers.

  I live in Turkey and I can't get anything through customs that's over 30 Euros I can't get the MESAs or the adapter boards for raspberry pis (No shipping to Turkey). BUT I have access to 3D printer control boards. like BTT Manta M8P and MKS SKIPR V1 or MKS Tinybee. Is something possible with these?

I would be very glad if you can point me in some direction. Thank you.

What are the chances of this being a slow SD card issue?
It sure points that way...

To tell the truth, whilst I haven't done any long term testing, I haven't seen this issue of my RPi-400.
When I build the image I put it through the basic tasks, and if I had of seen this issue arise I wouldn't have released the image, I would have deemed it defective and not fit for purpose.
Now we are going to require some more info, what monitor (brand model) screen resolution and such. And just to be sure I would like to know if this is a clean install without any extras added. If you can remember when was the last time you did an update.

And yes the RPi400 should give reasonable playback on youtube and reading pdfs shouldn't pose an issue. When I get the time I'll recheck things but as I said before I haven't seen this issue arise during testing and so far in the 6 months it has been out in the wild no one else has mentioned this.

One thing I would suggest is look at this thread, forum.linuxcnc.org/38-general-linuxcnc-q...l-images-only#325007 and take note of the video issue link & zswap link.

Post a screenshot so we know what you are talking about.

This is really more of a Debian/RPi isue, not a LinuxCNC issue.

A Raspberry Pi has a weak GPU, why would you use it for YouTube playback?

Use a Mac Mini, an old PC, or something else with an actual GPU (a dedicated GPU is better, but not essential; a good iGPU can be good enough).

The official LinuxCNC 2.9.4 image for arm64 is installed on a Raspberry Pi 400. There are strange partial graphical glitches in browsers, such as some pages or partial horizontal section of the page not displaying properly, while the rest is fine.

This was tested with Firefox ESR, but Chromium was also installed, and for example, the settings page for Chromium never displays properly. It would appear the underlying text and buttons/links are present but not visible, except by sometimes mousing over them. 

The problem appears to be only in browsers, not other applications. Youtube in either browser is also unusable, with graphical glitches on the player controls (YT buttons like play/pause/settings are either invisible or look corrupt).

Similarly, when opening PDF documents in browsers, the control buttons along the top of the document for Zoom/Download/Save etc are often invisible, but still present if moused over.

Also, Youtube video playback is extremely laggy, and that is including after removing the isolcpu=2,3 option. The goal on the Pi is just to familiarize with LinuxCNC and set up configs, not to run machines on it, so I'm not too concerned about the latency penalty in this case.. 

Has anyone else experienced this problem? 

Honestly, I would just add a  leaded 620 Ohm pulldown
resistor on the back of the breakout card and not make
any further modifications.
 

so a stiff pulldown to fight the pullup of the mesa card for the inputs?

I am using 7c81_5abobx2d firmware with BOB boards on P1 and P2.

Edit:
I did a little bit of digging.
- The relay pin P17 is IO7 of the Mesa ports, which is on the edge of the pull resistor array. I could desolder the array and put it back on shifted by one to remove the resistor of the pin.
- On the BOB there is a 10k pullup array on the relay pin. but the signal comes through a via in the middle of the pullup resistor and the 74HC... I could cut the trace between the via and the resistor to remove the pull up on the BOB
- solder in a pulldown resistor on the BOB (if for whatever reason the flat cable between the Mesa and BOB gets bad).

The 7C81 only has the option of all pullups and all pulldowns
on its I/O ports.

Simplest solution would probably be to add a stiff pulldown (say 620 ohms)
on the relay I/O pin. There is a firmware option for fixed parallel port type I/O
but currently its global (not per port), This firmware makes the parallel port
output pins default to outputs instead of inputs at startup or watchdog bite
What firmware are you using?

Maybe a stupid question, but how do you use the relay on those cheap MACH3 BOBs with the 7c81?

For the inputs to work I need to enable the pullups on the 7C81.
But enabling the pullups makes the relay close as soon as the BOB is powered.

Ideally I would want the relay to be open until linuxcnc is started and I tell linuxcnc to close the relay.

But the relay closing by default due to the pullups makes it unusable, or did I miss something?

Hi all,For context: I'm currently building the control system for a Samurai 120 CNC machine (please see the attached photo).Machine electronic hardware configuration:

• 3 × Leadshine EL8 EtherCAT servo drives
• 2 × 400W Leadshine motors with optical encoders and battery backup
• 1 × 400W Leadshine motor with motor brake, also with optical encoder and battery backup
• 1 × Beckhoff EK1100 EtherCAT coupler
• 1 × Raspberry Pi 5 for control

Current progress:

1. Successfully installed LinuxCNC on the Raspberry Pi 5
2. Updated to the latest version
3. Installed CIA402 using Rodw’s guide
4. Configured the Pi as an EtherCAT master

Where I need help: I'm struggling to understand how to configure LinuxCNC to communicate with the servo drives in a basic setup.From what I understand, LinuxCNC relies on three main configuration files:

1. .ini

   – Loads the user interface and references the

   .hal

   file

2. .hal

   – The Hardware Abstraction Layer, which defines machine characteristics and connects components

3. .xml

   – Extracts and defines information from the servo drives

I found Marco Reps’ GitHub repository, which uses a similar configuration. I downloaded all the files and attempted to launch LinuxCNC using the "el8" configuration, but it failed to load.
 Could someone please provide a step-by-step  on how to configure Linux CNC for my current setup? Any help would be greatly appreciated! 

I intend on eventually using the probe basic user interface as I an touchscreen this would work well with. https://samuraimachinetools.com/cdn/shop/files/IMG_9964.jpg?v=1722652171&width=1445
 

Current Situation and Probrem
I am trying to establish stable SPI communication between a Raspberry Pi 4 and an ICE40UP5K FPGA (IceShield) using LinuxCNC and the RIO framework.
While basic SPI communication seems functional outside of LinuxCNC, I am currently encountering unexpected behavior during runtime: the system consistently logs "WRONG DATA" with "HXHP" as the received header.
My goal is to understand what SPI response LinuxCNC expects from the FPGA, and how to configure both ends to ensure correct communication.

Environment

•     Raspberry Pi 4
•     LinuxCNC version: 2.9.4 (same behavior also observed in 2.9.3 and 2.8.4)
•     OS: Official LinuxCNC 2.9.4 Raspberry Pi 4 Bookworm image
•     FPGA: ICE40UP5K-SG48I (IceShield)
•     Clock source: Since gpio is not available on Bookworm, I use pigpiod to generate a 5 MHz clock on GPIO 4:
       

  #!/bin/bash sudo pigpiod pigs hc 4 5000000

    I also modified spiflash.sh to work with pigpiod under Bookworm

FPGA Status

• The Verilog design (rio.v) is written to return the SPI response header "data" (0x64617461)
• The FPGA’s LED is blinking and SPI data is returned via external tools. This suggests the FPGA is operating correctly with the supplied clock.

SPI Test Using Python
To confirm basic SPI functionality outside of LinuxCNC, I used this script:This consistently returns "data" from the FPGA, suggesting that low-level SPI transport is functioning properly.

Behavior in LinuxCNC

• In the rio_readwrite() function, logging shows the SPI response always begins with "0:02" (0x30 0x3A 0x30 0x32)
• However, the LinuxCNC log reports "WRONG DATA" with the string "HXHP" (0x48 0x58 0x48 0x50)
• I did not find any logic in the Verilog code that would return "HXHP"
• I suspect that "HXHP" is generated internally by LinuxCNC when an unrecognized or malformed header is received

Observations

• SPI communication appears to be working, and the FPGA is returning a response
• However, there may be a mismatch between the header format LinuxCNC expects and what the FPGA sends
• LinuxCNC may be replacing the unrecognized header with "HXHP" as a default or fallback

Questions

• Where in the LinuxCNC source is "HXHP" generated or substituted? Is this a fallback response?
• Is the "0:02" sequence a standard header sent by LinuxCNC under the RIO configuration?
• What header or message structure (e.g. MSGID) is LinuxCNC expecting from the FPGA?
• Are there documented or example SPI response formats compatible with riocomp?

I would appreciate any advice or clarification.
I can provide Verilog and riocomp.c sources if helpful. Thank you.