Advanced Search

My guess is that it's trying to mount the nfs share before the wifi interface is up.
So you may have to look through dmesg to see when the nfs share is being mounted and when the wifi interface is being brought up.
Do you have any issues trying to mount the share after the wifi network is up ?

There may be a way to do it via systemd that waits for the wifi network to come up, I've got a couple of ones that turn off the power related stuff for wifi, but only after the interface is up. Might be able to use the same mechanism to mount the shares once that interface is up.

I'd suggest this isn't a issue related to the Raspberry Pi platform but any situation where an nfs or samba share is automounted and the required interface isn't up at that time.

Trying to get nfs between workstation and mill.
Posted here hoping the RPi developers may have a solution.

nfs server - workstation: hp desktop ubuntu 24.04.
nfs client - mill: RPi 4B 4GB LC 2.9.4.
 
wifi is working fine.
sftp between the stations without issue.

nfs works after a manual mount on the client.
Cannot get nfs to mount automatically at start up.

The /etc/fstab file is populated (to the best of my searching).
Tried a couple of web suggestions, but no solution yet.

Looked through the startup log:
    - "mount.nfs: Network is unreachable".

Tried several web suggestions, including increasing the wait time.

Did some searching on the Raspberry Forum without success.

When I issue a terminal command "mount' after starting LC, there is a response about an old version and to use "systemctl-daemon reload".
After reboot, entered 'systemctl-daemon reload', got 'command not found'.
Tried 'systemctl daemon-reload', accepted without success.

Any suggestions getting the mount at start-up ?

John.

On the bright side I figured out what my problem was. I had followed the documentation with recommended the preconfigured xpatria raspberry pi build and that did make getting everything up and running easy but, I didn't think to git clone the newer Remora developments since that image was released so I was running the older halcompiled remora-spi which I'm sure now was causing me issues. Now that I have pulled the most recent Remora version and compiled remora-spi again with halcompile like the docuementation says to do, although I noticed that in an earlier post it was mentioned that you no longer need the SPI_clk_div=32 after the loadrt remora-spi component in the HAL file but, mine wouldn't come out of estop until I added that back into the line. I also had a grounding issue and some EMI issues that collectively were causing my spindle to throw errors and after that and the correct version of firmware on the Octopus and most recent Remora branch then it looks like I'm good now.

If you try to connect remotely via VNC after logging in with your username from the console, you'll get a gray screen. You'll need to log out from console.

LinuxCNC 2.9.5 has been released.

This is mainly a bugfix release, but includes a new modbus driver for
the Mesa UART (update/replacement for mesa_modbus with more
flexibility and configurability)

Packages for 2.9-uspace for amd64 (PC) for Debian Buster, Bullseye,
Bookworm and Trixie and for arm64 (Raspberry Pi 4/5) for Buster and
Bookworm have been added to the linuxcnc repository.
If you installed from one of our live images or Pi SD-card images then
the update should be available immediately.

If you  installed into a normally-installed Debian from the Debian
repositories then hopefully the new version can be queued up for the
next point release. If you can't wait then it is possible to add the
LinuxCNC repositories to the apt sources. One way to do this and
install the security keys is via the shell script here:
linuxcnc.org/docs/stable/html/getting-st...th_preempt_rt_kernel

At the moment the live-image installer and SD card images will install
2.9.4 but update should be trivial (and possibly automatic)

RTAI is still supported, but in the short term building from source is
likely to be the most expedient way to get 2.9.5 on that platform.

Highlights:

 * Backport new hm2_modbus driver to 2.9 branch.
 * Fix probe contact bounce triggering error during decel phase

Abridged list of other updates.

 * gmoccapy: change text to icons of undo/redo buttons to fit window size
 * tests: save.1 test removed. It's been skipped for 19 years.
 * halui: on startup, set the first configured axis as 'is-selected'
instead of X
 * halui: Don't create 'halui.axis.'- pins for unconfigured axes
 * qtvcp versa probe: remember setting of auto skew/zero buttons we reopened
 * PyVCP test: result file formatting fixes (#3551)
 * stepconf -fix human input names in wrong order
 * Tests: Add a test for PyVCP - Specifically Issue #3538
 * Deprecate gantry.comp
 * Fix #3538 - "halparam" tag not working in PyVCP
 * tests: Add a test for spindle INI speed limits function
 * Fix a race; add a test to ensure the 'result' and 'stderr' files
are closed before continuing to run 'checkresult'.
 * Fix command-line directories acceptance by correct expansion.
 * Fix a race between setting the signal handlers and marking hal_ready().
 * Gladevcp: Update the .ui and .glade files in the sample configs to Gtk+3.0
 * clarify documentation on stat 'gcodes' and (spindle)'speed' attributes
 * Merge pull request #3460 from
Sigma1912/2.9-Fix-preview-update-not-respecting-active-wcs
 * Don't use  RS274NGC_STARTUP_CODE when updating the preview
 * Merge pull request #3454 from Sigma1912/2.9_Fix_issue_3447
 * Gmoccapy: Fix very large numbers for spindle speed and 'Vc' in the
gui when using G96
 * Gmoccapy: Fix 'spindle.0.speed-out' pins being reset to wrong value
when using G96
 * Split declaration/assignment with label because it is not accepted
by the compiler in Debian 10 and 11.
 * Fix invalid escape sequence warnings from halcompile and hal components.
 * Fix missing parity error definition
 * Merge pull request #3412 from BsAtHome/backport_2.9_fix_update-pktuart-v3
 * Update, fix and reorganize hostmot2 PktUART to support V3.
 * debian: Updated policy standard to 4.7.2
 * orient: Commit 79c0966 had an un-noticed effect on the behaviour of
M19 reported in issue #3389
 * ServoToGo: remove old weblinks that now redirect to a spam site
 * halui -fix spindle override using direct value.
 * gmoccapy: fix setting to disable "run from line"
 * halscope: set button left and right padding to 0 to allow smaller window size
 * docs: update halscope channel off function + update images
 * qtdragon_hd_vert -add a sample config for vertical layout.
 * qtvcp -qtdragon_hd_vert: add a vertical layout version
 * Merge pull request #3339 from NTULINUX/ntulinux/2.9-fixes
 * interp_o_word.cc: Insert almost-certainly-missing "breaks" addresses #3290
 * qtvcp -vismach config cleanup: gantry_5axis, millturn, vismach_fanuc_200f

The full changelog can be seen at
github.com/LinuxCNC/linuxcnc/blob/2.9/debian/changelog

As always, we couldn't do this without the contributions from the
community, so many thanks to:

Alec Ari
andronick83
Bertho Stultiens
CMorley
DauntlessAq
David
Hans Unzner
Petter Reinholdtsen
Rene Hopf
Sigma1912
Steffen Möller
 

I posted something I thought might be helpful since it seemed to fix my problem but, then it started happening again.  My SPI interface keeps getting reset as well and only when my spindle gets turned on.  I already created a shielded cable between the SPI connections. I thought messing with the base servo speed helped in the ini file at one point but, I just tried again and got the same microcontroller reset.  After that I have to reset the microcontroller before I get a good status signal for the SPI connection and I can toggle machine power once again and communications work as well.  I guess it could be interference on the SPI interface still but, I'm not sure how that is happening. EDIT:  I guess after creating a shielded SPI cable it did work for longer before getting an SPI reset.  I still had issues and I just put a piece of tin foil over no directly onto the raspberry pi4 GPIO pins and it looks like all of my errors are gone so maybe some EMI was getting into the raspberry pi pins and resetting the controller somehow?  I'm still testing to see if my problem is gone for good but, fingers crossed.

Best bet is to google for the various internet resources for setting up vnc.
You may have some luck searching the forums, but it wasn't a package I thought needed, still don't, for running a CNC machine. I'm not a fan of running a CNC setup remotely.
If you just need to run an editor or even Linuxcnc remotely it can be via SSH.

I downloaded the official image from here; www.linuxcnc.org/iso/rpi-5-debian-bookwo...25-01-27-0140.img.xz
Everything is ok, linuxcnc and ethercat master is working, 

I am trying to connect via VNC from remote, when I connected to 192.168.1.122:1 via VNC's password, its connecting but there is only blank gray screen,
I installed tightvncserver also, its same,
What should I do?

Oh this old gem, the solution is to remove or purge the offending raspberry pi package. Its been mentioned many many times throughout the forum, the exact commands can be found with a quick search.

Gusgus wrote:

Hi again and thanks for all the help up until now!

I wan't to give more context and explain myself better, we have been using this cnc router since 2023, originally setup with a raspberry pi 3b and octopus pro combo, it has worked wonders and is amazing the only real issue is that the raspberry pi 3b was slow. Recently we made the change to a raspberry pi 5, we took the original .ini and .hal files which we then update to be compatible with the new remora version, we kept the same config.txt file. We installed the linuxcnc-raspberrypi5 image and installed the remora components as instructed in the documentation.

The issues we've seen: when we first loaded linuxcnc and ran the .ini file by double clicking on it and choosing linuxcnc as the app to run the ini file we then saw the raspberry pi 5 using rp1 driver alert, we initially thought this was error but figured this was just an alert and so continued. We then started testing leaving e stop we could but just for a moment, no more than 3s, we could even get to enable but non of the drivers actually enable. We then tested if this was the E-stop's fault but we assumed it wasn't since if we disconnected the estop we could exit estop at all, wehn it was properly setup we could but can't enable the steppers fisically. This isn't a stepper issue or driver issue since they get enabled with the raspberry pi 3.

Thanks in advance and thank you for all of the help until now! Oh and sorry for any grammar or spelling mistakes, english isn't our first tounge.

Ok, so I pulled out my octopus board and RPi5 to see what could be the issue. I found my working config and noted:

#SERVO_PERIOD = 1000000
SERVO_PERIOD = 5000000

Making this change to your config, I got it up and running. With the faster servo period the board was throwing so many communication errors.

Yesterday i got 5 of Z600 workstations, as life would have after a friend gave one for free to me as i service and maintain his laptops and PC from time to time, i asked for the price as he had another 7 home collecting dust, and after quite a bit of back and forth (and bickering) we agreed on another 4 for 100 Euro total, making it 25 Euro a piece!
Wasted yesterday evening and night, and today all day testing and installing those, organizing memory modules (several types of several sizes on all of them) ended up 4 having 16GB of ECC RAM and one having 24GB of ECC RAM and some left over 2GB and 1GB modules, all have 128GB SSD and some have and assortment of spinning HDD's from 80GB to 500GB, all have old NVIDIA Quadro graphic cards that now seem pathetic compared to a GTX1060/6GB or RX580/8GB that i promptly switched to on two of them, all have 2 of Xeon 4 core CPU's at 2.4GHz, and proprietary 650W power supply with a single 6 pin VGA power connector, and all weigh in at over 20KG !!!
So far tested with Linux Mint 22.1 and LinuxCNC 2.10 on 6.13 RT kernel, all have very good latency from short test i did. Will do more tests and also add a parallel port to one to test with as they do have PCI slots.
Have to go to the shop and finish 2 more installs, so for now i leave you with this:
Do NOT buy raspberry PI, buy everything else.

Hi again and thanks for all the help up until now!

I wan't to give more context and explain myself better, we have been using this cnc router since 2023, originally setup with a raspberry pi 3b and octopus pro combo, it has worked wonders and is amazing the only real issue is that the raspberry pi 3b was slow. Recently we made the change to a raspberry pi 5, we took the original .ini and .hal files which we then update to be compatible with the new remora version, we kept the same config.txt file. We installed the linuxcnc-raspberrypi5 image and installed the remora components as instructed in the documentation.

The issues we've seen: when we first loaded linuxcnc and ran the .ini file by double clicking on it and choosing linuxcnc as the app to run the ini file we then saw the raspberry pi 5 using rp1 driver alert, we initially thought this was error but figured this was just an alert and so continued. We then started testing leaving e stop we could but just for a moment, no more than 3s, we could even get to enable but non of the drivers actually enable. We then tested if this was the E-stop's fault but we assumed it wasn't since if we disconnected the estop we could exit estop at all, wehn it was properly setup we could but can't enable the steppers fisically. This isn't a stepper issue or driver issue since they get enabled with the raspberry pi 3.

Thanks in advance and thank you for all of the help until now! Oh and sorry for any grammar or spelling mistakes, english isn't our first tounge.

We have used this settings before, and the machine worked fantastic, the only change we've made is the change from raspberry pi 3 to 5 and the Remora version change. Well attempt config changes. Thankyou Scotta!

Hello! My team and I have been setting up a cnc using a raspberry pi 5 running remora to an octopus pro with spi, this then uses 4 Ext motor v1.1 to generate the steps using stepgen in the octopus config to generate movement with some DM556 drivers these are wired directly to the steppers. We have been having issues, when we boot LinuxCNC an error appears, raspberry pi 5 using rp1 driver. We belive this to be a warning to tell show that the rasp5 got recognized.

We haven't been able to enable the stepper drivers, the e-stop is working. We can enable but the moment we try to jog we get a joint following error this, caused by  the drivers not getting enabled and not getting any movement. 

Any ideas on what we could do?

This is the output of ip a

cnc@linuxcnc1:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 2c:cf:67:3a:15:bb brd ff:ff:ff:ff:ff:ff
    altname end0
    inet 192.168.0.153/24 brd 192.168.0.255 scope global dynamic eth0
       valid_lft 799842sec preferred_lft 799842sec
    inet6 fdce:a2be:2d61:0:2ecf:67ff:fe3a:15bb/64 scope global dynamic mngtmpaddr
       valid_lft 7124sec preferred_lft 3524sec
    inet6 2003:e4:9741:1e00:2ecf:67ff:fe3a:15bb/64 scope global dynamic mngtmpaddr
       valid_lft 7124sec preferred_lft 1191sec
    inet6 fe80::2ecf:67ff:fe3a:15bb/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether aa:57:f1:85:a9:88 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 2c:cf:67:3a:15:bc brd ff:ff:ff:ff:ff:ff

When connecting the eth1 port to my network switch I got an information from my router, that it assigned a new IP adress to the ethernet card with the MAC adress of eth1. So I assumed that it should be possible to reach that port via ping. This ping was done from a windows PC in my network. All four tries timed out. But looking to the result of ip a above, the IP adress is not shown on Linux side. This I did not see before.

The reason why I would like to use this second ethernet is because my workshop is in the basement of my house and the RaspberryPi is in a metal housing within a metal cabinet. Finally I like to use my devices hardwired instead of using WIFI. I thought it would be straight forward to put in an additional ethernet card, activate PCIe and then be able to use it.

Unfortunatelly I am not an Linux expert and I am not a native english speaker, so if I miss something from your advices please give me a hint. I will try to make it.