Raspberry Pi 4

I think the cpu freq can be throttled without temperature rise.
so I think all users should fix thier cpu freq regardless of good coolers

because:

---

I've built the rpi4 system using JT's instructions.
I had a very nice cooler fan mounted. ( ice tower )
Then I ran it for 6 hours and got max 33uS with 4 glxgears.
No browser or video player on this build.
Then i checked randomly on the cpu freq and temp.
The temp remained 38-40 deg, but the freq occasionally went to 600mhz from the typical 1.5Ghz.
Even tho there is no terrible latency hit,
I imagine its not good for a realtime system to have the cpu frequency cut in half.

So, I wrote a bash script to log the freq and temp and let it run overnite.

#!/bin/bash
vcgencmd measure_clock arm >> report.txt
vcgencmd measure_temp >> report.txt

then i added it to crontab
*/5 * * * * /home/pi/report.sh

The next morning I saw infrequent freq throttling to 600 000 000 but never a high temp.
"""
frequency(48)=600117184
temp=38.0'C
"""

Then I checked some things
"""
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
(NOTE I HAVE performance LISTED)
"""

then i checked max freq
"""
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
(NOTE MINE SAYS 1500000000)
"""

then to force that freq
pi@raspberrypi:~ $ sudo sh -c "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq"

(afterthought: i see i might do similar for max_frew, but didnt do that yet )

then re-ran the logging cron job
and so far ( 30 entries) looks good
"""
temp=39.0'C
frequency(48)=1500398464
... snip
frequency(48)=1500345728
temp=41.0'C
frequency(48)=1500345728
temp=39.0'C
"""

i am now looking at how to make this pedal to the metal rule apply on next boot
as i think the cmd line fix above is not persistant

hth
tomp

You can set force_turbo = 1 in the [pi4] section of config.txt. this will stop the frequency changes and keep it at 1.5 GHz.

Another sample. I am running the latest kernel I've built and apparently have all governors present, currently ondemand, basicly at 600 with an occasional sortie to 700.

temps reported are a little higher as my fan is a 12 volt video card running on 5 volts. So while actually running linuxcnc and driveing the spindle at 100 rpms, its still at 600 with a 44C temp

I am only logging one latency overrun, the one that accompanies the linuxcnc startup. latency-test period= shows around 16 u-secs. I have set in config.txt a cpu_freq of 800 and force_turbo=1 but haven't rebooted to put it into effect. I thought I had the slower governors disabled but it appears I should recheck that and rebuild again. But I spent some time playing with the machine saturday an was pleasantly surprised, with this kernels lowered latency I was able to raise the rapids by around 40% z and 30% x. The pi4 has a lot more cajones than a pi3 ever displayed, and am well pleased with what I've seen. if a reboot puts it at 800, thats more than it needs to run this 2 axis lathe.
I have 2 threads, the basic 1 kliohertz servo, and one running at 200hz which is more than fast enough to handle the jog dials as I fitted 2 of them to replace the manual cranks that aren't there any more.

I'm pleased as can be.

PCW wrote:

russell wrote:

Hi,
I'm in the process of moving my lathe over from MachineKit on a BBB to LinuxCNC on a RPI 4 with a Mesa 7c80, I've had to use master to get the INMUX support for the inputs but I'm now stuck setting up the spindle enables and direction outputs. I've got the motor drivers direction and enable inputs connected up to the Spindle Enable and Spindle Direction terminals on TB5 but I can't see anyway of triggering them from HAL - am I missing something?

Regards
Russlel

Yeah missing a better manual...

The spindle analog enable is part of the PWM hardware so enabled when
the PWMGen is enabled

The Optocoupler ENA (or forward) output is controlled by GPIO 20

The Optocoupler DIR (or reverse) output is controlled by GPIO 21

These are both active low so you would want to set both the is_output parameter
on both GPIO bits and set invert_output parameter on the enable pin
(and possibly on the dir pin depending on how the drive direction works)

Thanks. I've got most things working how I want them now, but I've got a couple of spare rotary encoders which I would like to try and use to improve the homing accuracy, it's only a small lathe so neither axis moved particuetly fast so I think the MPG inputs on the 7c80 would be fast enough but they are missing the index support. Is there any way of adding the missing functionality? Alternatively can I somehow connect then to the P1 header?

Regards
Russell

The MPG encoders are really intended just for that use.
Adding an index would need new firmware and driver support.

You can use the expansion port for additional encoder channels, but the bare
pins are susceptible to damage from overvoltages, so if you dont want to add one of
Mesa's fancy daughtercards, at the minimum you should add a 220 ohm or so
series resistor to any external wiring.

I don't mind buying a Mesa daughter card except that I will have to import one as they are not available in the UK, so I would like to do some proof of concept testing first.

I do have an old buffered parallel port break out board knocking around I could use but how do I configure the hostmot2 component to tell it about the new encoders?

Is the 7I85 the most appropriate card to add 2 encoders?

Thanks
Russell

We are using the 7i81. it has 3 26 pin connectors. It works quite well with our 3 axis cnc.

7 i ??

7C81

Yes the 7C80 and 7c81 are new and specialized for the Pi