Advanced Search

Isn't your pursuit somewhat of a wild goose chase? You're only running a servo thread so I'm assuming you have a hardware motion controller like a mesa card, and if that's the case, is there any benefit to having 20us max jitter vs 60 or even 80? I'm sure someone more knowledgeable will correct me if I'm wrong, but with a mesa board even 100us max jitter should be fine. In the context of linuxcnc (and real-time in general), it's more of a "works/doesn't work" rather than "this works faster".

I'm actually quite please with this computer. There are multiple threads here struggling with just the right raspberry pi config with a custom linuxcnc image, or threads about other SBCs working with linuxcnc at all - orange pi, banana pi, odroid and so on, while this one seems to work just fine out of the box with the regular x86 image. No messing about.

I'll do as tommylight suggested and run it overnight soon so we'll see, but that puts us back to the works/doesn't work thing. if it works fine with high jitter, it really doesn't matter that other cpus can do the same job with lower jitter, no?

Hey Richie, how did you go with the RPi 5? I have the same + Mesa 7i96s in Blenheim…

Thanks, I will give that a try tomorrow and report back.

Its a hardware issue. please read my tutorial here
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing

The good news is that the RPi and Mesa 7i96s are communicating and appeared to be doing so reliably using the Dragon GUI until a string of these messages appeared:

hm2/hm2_7i92.0: error queuing read! iter=xxx
hm2/hm2_7i92.0: error finishing write! iter=xxx

If I run the following, there appears to be dropped packets:

sudo chrt 99 ping -i .001 -q 10.10.10.10  /* forum.linuxcnc.org/27-driver-boards/4837...rite?start=20#266420 */

About 25% were dropped when using a 30 cm CAT cable (not sure what type, shown in photo above). Changing to a longer CAT 5e cable resulted in a tiny percentage of dropped packets. Nevertheless, the errors keep appearing when running Dragon GUI -- I'm not suggesting that Dragon GUI is the issue here.

Did this ever get resolved?  I have a Raspberry Pi 5 and 7i96s and I am seeing the same issues:

hm2/hm2_7i92.0: error queuing read! iter=xxx
hm2/hm2_7i92.0: error finishing write! iter=xxx

forum.linuxcnc.org/9-installing-linuxcnc...i-5?start=110#293125

Yup, I find it kinda funny that a site catering to technology uses such a terrible editor :-D

I have used a lot of forums but never seen one this bad :-D

If it wasn't for the great people here it'd just be too painful hahahah.

@0x2102
Hey man, thanks for posting that.  I haven’t had this problem before, but I like learning new info in case I ever do!!!  Nice…


@ zmrdko
Thanks for sharing your info.  I knew the “generic” component was slower as Dominik had stated so years ago, and I always try to avoid hardware that is not already in the driver… 

 

Now try to reducing those two settings:

sudo ethtool -C eth0 rx-usecs 0
sudo ethtool -C eth0 tx-usecs 0

If that errors out, try 1 or the lowest number the driver accepts.

Regarding Bjarnes comments on your issue about debian could you advise if you are using the image on the Downloads page?

Hi!
thanks for reply.

see output in attachment

Install ethtool and run this in Terminal:

sudo apt install ethtool
ip a
sudo ethtool -c "NIC CARD NAME" and post your output.

In essence you are trying reduce the settings (buffer) as much as you can.

You can change the settings with:

sudo ethtool -C "NIC CARD NAME" "NEW SETTING".

Some drivers allow to reduce to 0, some others require a higher minimum number.

Hi,

i would like to share some research findings.

I have acquired RPi 5 since I wanted to check linuxcnc performance on this new single board PC.
The performance leap compared to RPi 4 is staggering. I tried to hook up Delta B3 EtherCAT drives, which was pretty straight-forward.
Browsing youtube for linuxcnc ethercat videos I come across this one:

So I thought that I should try this on raspberry pi 5. 125000ns was too much, but 250000ns was mostly OK.
But with this cycle times, servo drives started to have troubles with getting to OP mode.
Guys at etherlab found out, that ethercat master driver generic (DEVICE_MODULES="generic") is only good for 1000000ns threads/cycle time.
To reach better cycle times, I was told to try "genet" driver wich is working fine on Raspberry Pi 4. (RPi5 and RPi4 has the same ethernet chip BCM54213PE)

But the final verdict is, that RPi5 uses macb driver (Cadence GEM) and not genet.
Thats why we are stuck with generic device module.

Link to etherlab issue thread:
gitlab.com/etherlab.org/ethercat/-/issues/104
 

I now have a RPi 5 8 GB model and Mesa 7i96S card. I have downloaded and installed onto a 32 GB micro SD card "LinuxCNC 2.9.2 Raspberry Pi 5 OS based on Debian Bookworm Raspberry Pi 5 Uspace compatible with Mesa Ethernet and SPI interface boards."

I have the Pi (10.10.10.1) talking over ethernet to 7i96S (10.10.10.10) following a W5 jumper change on 7i96S and Linux command:

sudo ip address add 10.10.10.1/24 dev eth0  /* this will work but DON'T USE THIS as it will not persist after a reboot */

ping 10.10.10.10

To ensure the settings persist after a reboot, AND noting that Linux networking commands seem to have recently changed, the following works:

nmcli con show  /* this will show the RPi 5 wireless and wired "ethernet" connections, and the NAME e.g. "Wired connection 1" for TYPE "ethernet" */

sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.10.10.1/24  /* dunno where this gets saved in RPi OS */

Test if persistent by rebooting, then typing again:

nmcli con show  /* DEVICE should now = "eth0" */

ping 10.10.10.10  /* ping the Mesa 7i96 card -- I get a ping time of 30-40 us */

This editor is ghastly

I have now removed all encoders from the JSON and reinserted the PWM generators and can confirm that all 5 axes are now working.
I can perform error-free homing and move the axes manually in both directions.

Here is the output from my test:

cnc@raspberrypi:~$ linuxcnc
LINUXCNC - 2.9.2
Machine configuration directory is '/home/cnc/linuxcnc/configs/test1'
Machine configuration file is 'test1.ini'
Starting LinuxCNC...
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX realtime
Found file(REL): ./test1.hal

identityKinematicsSetup: coordinates:XYYZA
Joint 0 ==> Axis X
Joint 1 ==> Axis Y
Joint 2 ==> Axis Y
Joint 3 ==> Axis Z
Joint 4 ==> Axis A

litexcnc: Loading Litex CNC driver version 1.1.0
litexcnc: Loading and registering default modules:
litexcnc: Registered module gpio
litexcnc: Registered module pwm
litexcnc: Registered module encoder
litexcnc: Registered module step
litexcnc: Setting up board drivers:
litexcnc: Registered driver eth
LitexCNC-eth: connected to board on '10.0.0.10:1234'
litexcnc: Setting up modules...
litexcnc: Reading 28 bytes
litexcnc: - Watchdog
litexcnc: - Wallclock
litexcnc: - gpio ... done!
litexcnc: - pwm ... done!
litexcnc: - step ... done!
litexcnc: Creating read and write buffers...
litexcnc: Base addresses: init: 00000000, reset: 0000003C, config: 00000040, write: 00000044, read: 000000B8
litexcnc: - Write buffer: 116 bytes
litexcnc: - Read buffer: 88 bytes
litexcnc: Exporting functions...
Found file(REL): ./custom.hal
litexcnc/5A-75B:V8.0: Watchdog timeout (3000000 ns) is dangerously short compared to litexcnc_write() period (2400000 ns)
note: MAXV max: 25.000 units/sec 1500.000 units/min
note: LJOG max: 25.000 units/sec 1500.000 units/min
note: LJOG default: 2.500 units/sec 150.000 units/min
note: AJOG max: 25.000 units/sec 1500.000 units/min
note: AJOG default: 25.000 units/sec 1500.000 units/min
Warning: Forward kinematics must handle duplicate coordinate letters:yy
note: jog_order='XYZA'
note: jog_invert=set()
task: main loop took 0.158369 seconds
task: main loop took 0.234904 seconds
task: main loop took 0.142043 seconds
Shutting down and cleaning up LinuxCNC...
task: 4833 cycles, min=0.000033, max=0.234904, avg=0.010225, 3 latency excursions (> 10x expected cycle time of 0.010000s)
litexcnc: LitexCNC driver unloaded
Note: Using POSIX realtime


Ps: I don't know if this is important. I almost always have to start Linuxcnc twice because the watchdog triggers immediately the first time. This little bug has been there since the beginning of my tests.