Advanced Search

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.

This is a general Linux / Debian question rather than a LinuxCNC question, so you might need to broaden your search.

raspberrytips.com/set-date-time-linux/

Might help?

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.

Habe das Problem gerade gelöst. Auf der Downloadseite von FreeCAD gibt es 2 Linuximages: x86_64 und aarch64. Da LinuxCNC bei mir auf einem Raspberry läuft, funktioniert nur Letzteres. Aber es funktioniert 

Die heruntergeladene Datei kann man ohne Installation ausführen, wie in der Anleitung oben beschrieben: 

After download, right click on it, properties, permissions, check "Allow executing file as program", close, double click on it.

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?