Advanced Search

Hi RNZ,
Newbie here and very interested in the RPi5 + Mesa 7I96S combo for a new Plasma CNC build.

You mention a 5V @ 3A power supply. Raspberry Pi recommends 5.1V @ 5A. Mesa recommends 4.75 to 5.25V @ 0.4A.

Could this contribute to the issue? Thanks.

 
Hi,
I am currently doing a project with EC500_v5 using remora firmware. I have flashed the controller board with the remora firmware and have done all the necessary steps mentioned in the remora documentation. When I faced certain problems, I had refered this forum and I could solve those issues on my way, Now I am able to open the LinuxCNC, but I am not able to come out of the e-stop. I am adding all the steps that I had done till now. I would like to get some help from this community for solving this problem.These are the steps that I had followed. I would like to know whether I have done anything wrong in this. I am new to LinuxCNC and trying to learn more about it. So sorry if I ask silly questions.
 

1. Flashed EC500_V5 with Remora Firmware
   1. File downloaded from the Github link ( github.com/scottalford75/Remora-RT1052-cpp/tree/main/Firmware )
   2. Latest version of firmware was installed: remora-rt1052-3.1.2.bin
2. Raspberry Pi LinuxCNC image downloaded from the link provided in Remora Documentation ( github.com/Expatria-Technologies/remora-flexi-hal/releases ) and installed to RPI4 Model B
3. Connected RPI4 with EC500_V5 (RT1052 Chip) by Ethernet cable
4. Copy files to upload the configuration file to the LinuxCNC
   1. Downloaded the files from Github ( github.com/scottalford75/Remora-RT1052-c.../remora-rt1052-basic )
   2. Copy the folder remora-rt1052-basic to the folder LinuxCNC > Configs
   3. Copy the folder components to the folder LinuxCNC
5. Installing the Remora Components
   1. sudo halcompile –install remora-eth-3.0.c
      1. Result: Success
6. Ethernet Setup
   1. Open DHCP configuration in terminal
      1. sudo nano /etc/dhcpcd.conf
   2. Navigate the file to the section ” Example static IP configuration ” , uncomment this section (by removing the #), modify it as follows, then save and exit nano (ctrl X, then Y then enter)
      1. interface eth0
         static ip_address=10.10.10.11/24
   3. Reboot you Raspberry Pi
   4. Verified that the ip address of the RPI4 has changed to 10.10.10.11/24 from the network settings window
      Terminal Emulator Command: hostname -I
      Result:
      10.10.10.11 192.168.40.209 2401:4900:4bbf:1813:83b0:6004:289d:6227
7. Upload the configuration file to the LinuxCNC
   1. Upload the configuration file – python3 upload_config.py ec500-rt1052.txt
      1. Result:
         Traceback (most recent call last):
         File “upload_config.py”, Line &, in <module>
         import tftpy
         ModuleNotFoundError: No module named ‘tftpy’
   2. Tried to install tftpy using the command
      pip install tftpy
      It showed that tftpy-0.8.2 got installed successfully
   3. Upload the configuration file – python3 upload_config.py ec500-rt1052.txt
      1. Result:
         Traceback (most recent call last):
         File “upload_config.py”, Line &, in <module>
         import tftpy
         ModuleNotFoundError: No module named ‘tftpy’
   4. Installed : pip install selenium
   5. Upload the configuration file – python3 upload_config.py ec500-rt1052.txt
      1. Result:
         Valid JSON config file, uploading to board
         Config file length (words) = 1716
         Config file length (bytes) = 6862
         Reminder = 2
         Padding added = [0, 0]
         Config file length with padding (bytes) = 6864
         CRC-32 = 0x580751a8
         (Furthermore sentences were there: Attached with this message)
8. Reboot the Controller Board and RPI4
9. Open LinuxCNC: Application > CNC > LinuxCNC
10. Open the configuration: My Configuration > remora-ec500 basic > remora-ec500-rt1052
    1. Error:
       Debug file information:

Note: Using POSIX realtime
remora-nv: dlopen: /usr/lib/linuxcnc/modules/remora-nv.so: cannot open shared object file: No such file or directory
./remora-nvem.hal:9: waitpid failed /usr/bin/rtapi_app remora-nv
./remora-nvem.hal:9: /usr/bin/rtapi_app exited without becoming ready
./remora-nvem.hal:9: insmod for remora-nv failed, returned -1
1798

1. 1. Downloaded the file from github.com/scottalford75/Remora-NVEM/tre...Components/Remora-nv
      and copied the file Remora-nv to LinuxCNC > Components
      Installed the file using the code:
      sudo halcompile –install remora.c
   2. Rebooted RPI4 and tried opening LinuxCNC
   3. Error: nvmpg file is missing
   4. Copied nvmpg.c file to LinuxCNC > Components
      Installed it using the command:
      sudo halcompile –install nvmpg.c
      Installed successfully
   5. LinuxCNC Axis GUI opened
2. Rebooted RPI4 and EC500
3. Check out of E-Stop - Failed

I had tried reflashing EC500 but no change. 
Hope to get a help on this.

- Aravind
 

Here in New Zealand I should be sleeping...

I have been searching for "Broadcom" and "coalesce" and have found nothing so far. However, I did find that both the Pi 4 and Pi 5 both use the same Broadcom chips:

Broadcom BCM54213 Gigabit Ethernet PHY

Source: en.wikipedia.org/wiki/Raspberry_Pi#Specifications

The good news for me at this stage (following Rod's suggestion) is that I have run 500,000 pings between my Pi 5 and 7i96s and unlike previous horrors there were 0 lost packets !!! I am now running it overnight with a target of 30,000,000 pings, so here's hoping.

Thanks a lot guys for the pointer on this. The learning curve is steep, but if the RPi 5 can perform, it would be a great solution. It boots to the log screen in about 5 s so is pretty quick. It would be nice to physically mount it on or above the Mesa card...

If you are willing and able, could you take a minute and describe what you think the coalesce setting is doing? My understanding is that once an interrupt is generated by an incoming packet, future interrupts are disabled for some time period and replaced with polling in order to reduce CPU overhead required by the interrupt operation.

Hi, I’m hoping that someone with a RPi Raspberry Pi 4 or 5 or a LinuxCNC desktop/laptop and Mesa 7i96s (or similar Ethernet card) can give me a little bit of assistance.

Could someone please try pinging the Mesa card for 5 or 10 or 15 minutes using the following commands to see if the ethernet comms stops communicating?

I have tried this myself using quite a few different permutations as hinted at in this post title, and in every case I have found the ethernet communications to fail within a few minutes. I am documenting this now and will post it below in a day or two.

==========================================================================

These are the commands I use on a fresh OS install and with Mesa card set to 10.10.10.10 using the W5 jumper.

nmcli con show // look for the ethernet name, probably “Wired connection 1”

sudo nmcli con mod “Wired connection 1” ipv4.addresses 10.10.10.11/24  // See the ethernet port to this address with mask 255.255.255.0

ping 10.10.10.10  // ping the Mesa card to see if the ethernet comms is working (assuming card is at address 10.10.10.10)

sudo chrt 99 ping -i 0.001 10.10.10.10  // repeatedly ping the card at 1 ms intervals and wait to see if the comms stops (5 minutes typ. in my experience)

==========================================================================

If you don’t get a failure of the communications, could you please post the version of Linux that you are using? You can use the following command.

uname -a

Thanks in advance.

For reference: 7i92 intermittant comms --->  forum.linuxcnc.org/27-driver-boards/3656...2-read-error?start=0

 

After about 10 lots of 5000 packets, we lose 4 packets. Note that the time also increased from a series of 5003-5004 ms and jumped up to 5040 ms. So we lost 4 packets at a cost of 4x10 ms...

cnc@linuxcnc:~$ sudo chrt 99 ping -i .001 -q 10.10.10.10 -c 5000
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

--- 10.10.10.10 ping statistics ---
5000 packets transmitted, 5000 received, 0% packet loss, time 5003ms
rtt min/avg/max/mdev = 0.101/0.108/0.127/0.004 ms
cnc@linuxcnc:~$ sudo chrt 99 ping -i .001 -q 10.10.10.10 -c 5000
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

--- 10.10.10.10 ping statistics ---
5000 packets transmitted, 5000 received, 0% packet loss, time 5004ms
rtt min/avg/max/mdev = 0.102/0.110/0.134/0.004 ms
cnc@linuxcnc:~$ sudo chrt 99 ping -i .001 -q 10.10.10.10 -c 5000
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

--- 10.10.10.10 ping statistics ---
5000 packets transmitted, 4996 received, 0.08% packet loss, time 5040ms
rtt min/avg/max/mdev = 0.102/0.109/0.242/0.005 ms

Mmmmmm.

Back to 10.10.10.11 on the Pi 5 and the ethernet packet losses are still there.

I have moved the Pi PSU to my iPad PSU which can supply 5V @ 3A. I am assuming that with all Apple's wealth, they have built a decent USB-C SMPSU.

sudo chrt 99 ping -i .001 -q 10.10.10.10 -c 5000

5000 packets transmitted, 4995 received, 0.1% packet loss, time 5049ms

rtt min/avg/max/mdev = 0.101/0.110/0.262/0.004 ms.

Is it the RPi OS?

Ok, maybe this helps...

Originally I was using 10.10.10.1 as the IP on the Pi 5.

sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.10.10.1/24

ip addr /* returned 10.10.10.1/24 */

For the past day however I have been using 10.10.10.11 because I read somewhere never to use the dot-1.

So I changed back to dot-1 and was able to get intermittant packet loss -- usually 0%, sometimes 1 packet if I used Ctrl+C (see previous posts). In one instance I was able to lose 7 packets.

Further, I was able to lock up the ethernet again.

What happens is I run this command

sudo chrt 99 ping -i .001 -q 10.10.10.10 -c 50000

and I note that the green LEDs on the ethernet are no longer flashing at some point. So I Ctrl+C and there are lots of lost packets (23% or something like that).

But running a ping 10.10.10.10 also now fails, but if I run this again

sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.10.10.11/24

then the ping starts working again and we are all good to go again.

So........ is my sin that I used 10.10.10.1 and it is conflicting with the default gateway that I have not set anywhere but is perhaps defaulting to that IP address?

Looks fine so far.

To try encouraging packet loss, I have plugged in a brushed electric drill into the same plugbox and revved it, and then plugged in a desktop PC with SMPSU. Still 0% packet loss over 10x sends of 5000 packets. Capacitors are not fitted.

Micro SDCard.

I ran

/opt/vc/bin/vcgencmd measure_temp

So the Pi is sitting at 48.8. Running

sudo chrt 99 ping -i .001 -q 10.10.10.10 -c 50000

50000 packets transmitted, 50000 received, 0% packet loss, time 50045ms
rtt min/avg/max/mdev = 0.102/0.112/0.197/0.006 ms

/opt/vc/bin/vcgencmd measure_temp
temp=50.5'C

So the wee fan and large heatsink appear to be holding the temperature down with a 50 s length increased load.

So....... this morning the Pi 5 has been quite stable in terms if ethernet comms. I might naively be thought to have caused this because I added 1x 0.1 uF and 1x 47 uF/16 V electrolytic capacitor across the blue terminal block (photo a couple of pages back) which is across the +5V / 0V rail.

I did this for a few reasons. First, because yesterday I plugged in the 7i96s while the Pi was running which may have caused the Pi to reset. Possibly the voltage at the Pi dipped due to 7i96s capacitance. I don't know if the Pi has any decent amount of power supply capacitance -- perhaps it is hidden under the heatsink (not a good place for electrolytic capacitors to live).

Second, the 5V/3A Meanwell PSU datasheet does not specify the output capacitance (or stability if you add capacitance). But in any case, the resetting of the Pi could suggest it doesn't have a lot of output capacitance.

Third, the 5V rail wiring is a bit long and all over the place, so could be picking up noise from other appliances, so this could suppress it a bit.

I also raised the Meanwell 5V rail voltage from 5.0 to 5.1V at the PSU terminals. Voltage drop in the wiring is about 100 mV according to my dodgy DMM, thus perhaps the rail was causing instability.

Well, things were quite stable, so I reversed all of the above and things are still stable !!! I can repeatedly send 50,000 packets with 1 ms spacing and get 0% loss.

Booting from MicroSD or NVME?
If first, try a different one, if you can.
Or a USB stick...
-
If NVME, skip the above.
-
Also, in a terminal
sensors
should show temperatures, if the processor is above 60-65C, slap some cooling on it.

LOL wasn't sure whether you were having me on or not... anyways, I unplugged the wireless KB/mouse dongle and replaced it with a wired KB....... the 1x dropped packet issue remains. Weirdy.

Try another keyboard.

Probably not important, bu I cannot duplicate that:

pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
532 packets transmitted, 532 received, 0% packet loss, time 531ms
rtt min/avg/max/mdev = 0.073/0.083/0.110/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
500 packets transmitted, 500 received, 0% packet loss, time 499ms
rtt min/avg/max/mdev = 0.071/0.083/0.116/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
1143 packets transmitted, 1143 received, 0% packet loss, time 1142ms
rtt min/avg/max/mdev = 0.072/0.083/0.111/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
908 packets transmitted, 908 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 0.073/0.083/0.114/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
565 packets transmitted, 565 received, 0% packet loss, time 564ms
rtt min/avg/max/mdev = 0.072/0.083/0.114/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
421 packets transmitted, 421 received, 0% packet loss, time 420ms
rtt min/avg/max/mdev = 0.072/0.083/0.112/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
332 packets transmitted, 332 received, 0% packet loss, time 331ms
rtt min/avg/max/mdev = 0.073/0.084/0.116/0.007 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
381 packets transmitted, 381 received, 0% packet loss, time 380ms
rtt min/avg/max/mdev = 0.072/0.084/0.112/0.007 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
588 packets transmitted, 588 received, 0% packet loss, time 587ms
rtt min/avg/max/mdev = 0.073/0.083/0.120/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
484 packets transmitted, 484 received, 0% packet loss, time 483ms
rtt min/avg/max/mdev = 0.073/0.084/0.122/0.007 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
452 packets transmitted, 452 received, 0% packet loss, time 451ms
rtt min/avg/max/mdev = 0.073/0.084/0.109/0.006 ms