Advanced Search

Just received notification and confirmed am64 permissions for the packages have been corrected. Thanks to Andy

I've emailed those that have access, one gentleman is away and can not check, the other gent is on the other side of world, I'm In Australia he is US based, so we will just need to wait for answers.

I have the same issue with RPI5

Taking an educated guess, it could be a permission issue, using the link you provided and removing the filename gets a directory listing in a browser, 403 is there when trying to download, other files are accessible.
Hopefully Andy will become aware of this, one option might be to access either the mailing lists, I'm banned due to comments on the origins of Code of Conducts and implementor, or GitHub.

When trying to install the update for 2.9.5 on a Raspberry Pi, I receive a security error when attempting to fetch The error is:

Forbidden
You don't have permission to access this resource.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

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.

I have the same problem with Raspberry 5 and 7i95T everything works fine when i use 7i96S but when I connect the 7i95T no light in ETH connector the CR15 and CR16 flash. When I turn 5V up to 5.3V then the 7i95T work

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.