Advanced Search

Desiccant sounds good at first, but these do "fill up" quickly. I have dozens of these bags in a 3D printer filament storage container. Even though it is completely sealed (with a gasket), all those bags are only good for about a year. Then they all must be baked at 110degC for 8-12h to rejuvenate them; moisture is insidious.

If you try this, place a quality hygrometer inside. Will likely find that the humidity stays low for only a month or so, even with a good seal.

The moisture alone probably is not causing the inability to start. The way most computers and power supplies are designed, just is not favorable to low temperatures. Very few are, because that is not a typical use case for a computer. Section 5.6 of the RaspberryPi4B says that is good down to 0degC - but then must consider whatever power supply is used for it. The characteristics of semiconducting materials changes as temperature changes, so functionality at low temps has to be something designed into it. Once had a quirky home computer that "complained" at 19degC and refused to run at 18.

If it were my machine, I'd put a heater (like a hair dryer on low setting) near the computer, along with a thermostat. Set the thermostat to say 20degC, and just let it warm up until the thermostat starts cycling. Of course need to be careful nothing can get too hot. Warming should take an hour or more - rushing it is not advised; the whole computer needs to warm up slowly. Then run the machine. That may be easier than re-engineering a quirky power supply or replacing the computer.  Unless anyone knows of an industrial-rated computer (and power supply.)  

I want to connect my spindle to a 5 Axis Breakout Board Interface Adapter via a raspberry pi5. I can control the stepper motors (XYZ). I just can't control the spindle. Is there an example for the HAL file?

If I bypass the relay contact. Then the spindle will rotate to the maximum. If I press the + button it slows down. When I press the - button it speeds up. When I press the stop button, it starts running at maximum speed. 
Anyone have a solution?

Greetings Philip

Cant wrote:

Pinium it

Done.
Thank you.

You know, that's not really helpful at all. Why is it no one wants to give any info that may help others diagnose a problem ? It's like pulling teeth, some kind of demented game.

Thank you! Have you tried to install ethercat on these images? I can't get it to work. However on a older image (with older kernel) you have posted it works without issue.

Pinium it

Should we nail it ...hmmm pin it ?
And adding the download link would be good.
Thank you.

First lets talk about the images.
1: They are based on Debian repos built by a collection of custom scripts.
2: Whilst some images have been written to SD card via RPi Imager Balena Etcher is recommended.
2a: If you use Linux there are plenty of other tools, Ubuntu\Mint has USB Image writer.
3: If you use the RPi Imager any adding of user or wifi info does not work. As the image is a custom one, only the kernel is built from RPi Sources.
4: If you are using an Rpi5 & a 7c80 0r 7c81 the driver to be loaded is hm2_spix
5: If you are using an RPi4 & a 7c80 or 7c81 the driver to be loaded is hm2_rpsipi
6: The images now have the SPI interface enabled by default.
7: Location of config.txt  /boot/broadcom/config.txt once again this is a custom build.
8: raspi-config is not in the image, the tool to use is menuconfig.
9: The default username is cnc.
10: The default password is cnc.
11: The images are not meant to be a fully fledged daily driver Operating System, the are just enough to run Linuxcnc.

Links to images:
www.linuxcnc.org/iso/rpi-5-debian-bookwo...25-01-27-0140.img.xz
www.linuxcnc.org/iso/rpi-5-debian-bookwo...7-0140.img.xz.sha256

www.linuxcnc.org/iso/rpi-4-debian-bookwo...23-11-17-1731.img.xz
www.linuxcnc.org/iso/rpi-4-debian-bookwo...7-0404.img.xz.sha256

Hi! I've tried to install ethercat to the latest RPi5 image, however it does not work, seems to be some kind of kernel mismatch. I've managed to install it and get it working with cornholio's image found here (forum.linuxcnc.org/9-installing-linuxcnc...berry-pi-5?start=310). Any idea what might be the issue? Since I'm doing a fresh install I kind of want to install the latest :) Thanks!

Over the weekend Andy released linuxcnc 2.9.4
To upgrade an existing bookworm release running version 2.9 all you need to do is to typeAnd go and have a cup of coffee

The ISO has also been upgraded for new installs on Intel X64 hardware. Grab it from the LinuxCNC downloads page.

The raspberry pi has not been upgraded but I've roped in Cornholio to help build images for release via linuxCNC repository so stay tuned.

Please join me in thanking Andy for his tireless work :clap:

Look under /boot there should be a folder called broadcom, or something and config.txt will be there.
The image is not a Raspbian OS based one but based on plain Debian but with a suitable kernel.

How did you enable SPI? I didn't find it in "sudo menu-confg" and "sudo raspi-config" command not found.

Have you tried menu-config to configure the wireless network ?
will show whats happening with the wireless network during connection, then you can use google to search for any issues you see, eg associating, disconnection and the like. As this will be a general Linux issue.

gene_weber wrote:

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:

skew_tick=1 kthread_cpus=0-2 irqaffinity=0-2 rcu_nocb_poll rcu_nocbs=3 nohz=on nohz_full=3 isolcpus=3

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.
[code]crontab -e
Add the following line:
[code]@reboot sudo sysctl kernel.timer_migration=0


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.

[code]#!/bin/bash
#
# Run with the SCHED_RR real-time policy at the highest priority level (99)
# Uses chrt to switch the process policy and priority immediately after launch.
#
# Gene Weber - January 2025
#
# "The difference between SCHED_FIFO and SCHED_RR is that among tasks with the same priority,
# SCHED_RR performs a round-robin with a certain timeslice; SCHED_FIFO, instead, needs the task
# to explicitly yield the processor." -Claudio

priority=99

# Truncate $1 (the command) to 15 characters starting at 0.
command=${1:0:15}

# Execute the command line provided to rrt as a background task.
`$@` &

# Get the process ID of the command.
PID=`pgrep $command`

# Change the real-time policy to SCHED_FIFO with a priority of $priority.
sudo chrt -r -p $priority $PID


I named it rrt (run real-time). So to launch latency-histogram it's simply:
[code]rrt latency-histogram --nobase --sbins 1000

All spawned sub-processes inherit the policy and priority. So if linuxcnc is launched with rrt:
[code]rrt linuxcnc
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.
[attachment=67004]final-16Jan2025-3117.png[/attachment]
 

[/code][/code][/code][/code][/code]

 

I think it's just easier to isolate 2 cores, it really doesn't affect performance. And reading the docs, mainly pertaining to amd64, the general rule is to isolate cores on the same physical die, for reason beyond my pay grade.

One thing that might be worth of note, as development moves along, is to check the Makelfile in the top of the directory as minor revisions can change for the the rpi-linux kernel.

Or you can run