Advanced Search

Hi, thanks for your response!
Do you happen to have a link to that specific thread? I might have missed it.

I've read a lot of posts and tried many things in both the BIOS and on the CNC machine over the past month, but nothing seems to help so far. I haven’t tried any bootloader or CLI-based options yet, so that might be worth exploring next.

That's why i have the feeling i am missing something obvious because this is my first AMD CPU machine. In the past i had 2 intel systems before and never had this extreme latency. Also i always used my AMD Firepro graphics card. So the GPU did not change over time.


::EDIT:: Alright isolating cores seems to be a step in the correct direction. I changed my GRUB conf to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3 idle=poll processor.max_cstate=0 amd_pstate=disable"
to free up my core 2 and 3. If i do a latency tests i now have a servo thread < 25 000 and a base thread < 120 000. So that is better. I think i it still not ideal to have such a high basethread... still the:
- joint 0 following error
- unexpected real-time delay

errors even if i start linuxcnc on the isolated cores via #!/bin/bash
taskset -c 2,3 linuxcnc /home/npostma/linuxcnc/configs/CNC/CNC.ini

Validated with `ps -eLo pid,psr,comm | grep -i linuxcnc` that it did run on the isolated cores. I also see in HTOP that the cores are isolated. No processes go to them.
 

Thanks again!

There's quite a few threads regarding latency, there's a quite a long one from just this week.
Your max speed will be a function of step per rev and your base thread.

You could try isolating the last 2 cores via the kernel command line.

That is because the PP uses G18 to rotate the coordinate system for milling.
Have you tried setting the rotational axis to Z as suggested here:
forum.linuxcnc.org/10-advanced-configura...hine?start=50#327942

The underlying problem is that linuxcnc applies the x-,y-z- tool-offsets internally, so the tool-length is automatically subtracted from the Z position shown in the DRO. That is why the kinematic model for milling has the tool spindle pointing in the negative machine Z direction and the model for turning has it pointing in the negative X direction.
While it might be possible to remove the tool-offset as linuxcnc applies them and add them to different axes in the kinematic I'm rather skeptical that it is worth the effort.
You need to remember that the planner currently has no information about the custom kinematic used, neither does the preview. The nice thing about TWP is that you can load any G17 XYZ milling toolpath and it will be displayed correctly in the screen.
Generally speaking limit violation checking and tool path preview will only be of limited use for more complex kinematics.

Note though that limit values can be changed when changing kinematic modes. For an example see:
github.com/LinuxCNC/linuxcnc/tree/master...xis/vismach/millturn

The actual values are changed using executable Mcodes:
github.com/LinuxCNC/linuxcnc/tree/master...mach/millturn/mcodes

Thanks for your interest! I made several modifications to qt_auto_probe_tool.ngc to improve tool length offset management and work coordinate independence.

Changes Made:
Separated tool length offset (G43) from work coordinate systems (G54/G55), making the tool table more intuitive.

The probe height was defined in machine coordinates and probed at the tip of the spindle.

Ensured tool length offset remains consistent regardless of WCS changes.

Thanks!

Hi all,

It’s been (far) too long since I last had time for CNC projects. Fortunately, things have settled down a bit lately, and I’ve been able to pick up the hobby again. However, getting my machine up and running has proven to be more of a challenge than expected.

My old Intel setup (with a 4790K) had both a faulty motherboard and RAM, so I replaced it with an ASUS AM4 board and a Ryzen 5600 CPU. Since then, I've been struggling with what seems to be very high latency.

To make matters worse, I used to run LinuxCNC 2.4, but I’ve now reinstalled everything using the latest stock ISO (2.9 with the PREEMPT-RT kernel). Unfortunately, this means my old configuration is no longer compatible.

I’ve uploaded my current settings, including the BIOS changes I’ve made in an attempt to reduce latency. At this point, my first goal is simply to get the axes moving at a reasonable rate. Right now, I can’t get it to move faster than about 1 mm/sec (rough estimate) before I run into either a joint 0 following error or an error about the base thread timing.

If anyone has tips or suggestions based on my setup or config files, I’d really appreciate the help. The machine used to run at a speed much faster than the tool could handle, so I know it's capable — I just need to get the configuration right again.

I’m aware that my .hal and .ini files likely need significant changes. I've done my best to port over the old configuration, but clearly, it’s not quite there yet.

Thanks in advance for any insights or advice!

The images are from 1 to 12, replace the number in the URL. I cant post that many links
www.doingcode.nl/images/linuxcnc/1.jpg

Hello Aciera,

i spend more time with it and found one more challenge.

While working with TWP i saw a problem, that it does twist the workplane perfectly but it also changes the axis definition.

Z Integrex is becoming X (Conventional)
X Integrex is becoming Z (Conventional)

Y stays Y

While this behavior can be surely handled in the PP, its a bit of a mess in LCNC. Soft limits are fairly difficult to define and in AXIS GUI it also looks a bit messy. The Doosan PP also does not change Z/X definition, when G368 is posted. And of course the key binding is also off in TWP mode.

The question is now: Can G68 keep the original Integrex Axis definitions ?

I had similar situation with qtpyvcp. I am using Debian bookworm with linux 6.12.12+bpo-rt-amd64. Linuxcnc 2.94 run in place (RIP).  QTPYVCP version 5.0.2+7.gla6d27f4 in developer mode under venv. I resolved the problem partly by sourcing linuxcnc (source ~/your rip path/linuxcnc/scripts/rip-environment). This allowed me to run qtpyvcp -h (as described in the documentation). The next step I tried to run the tutorial encountered the same problem as spumco

forum.linuxcnc.org/qtpyvcp/51930-qtpyvcp...cp-tutorial-problems

I could not resolve problem mentionard in the link above.  In the above link moderator Lcvette mentioned to use scripts from probe basic but I did not load probe basic so I don’t know what is in the content of the scripts.However, I was able to run qtpyvcp designer by issuing the following command ‘editvcp’ that got me a pop up and I picked ~/your-path/qtpyvcp/vcp/tutorial/src/mypvcp and selected config.yml this got qt designer to load with all qtpyvcp templates but tones of warnings.

I am still trying to find how to setup qtpyvcp to behave as indicated in the documentation. Hopefully if qtpyvcp moderators reads this message they would publish the content of the probe basic script as mentioned in the link above, or even better include the script into qtpyvcp installation package (make easy for linux dummies). Also, the documentation should mention that linuxcnc rip must be sourced before attempting to run qtpyvcp.

besi99 wrote:

....
$ chmod +x besnik/home/Downloads/linuxcnc-install.sh
....
$ cd besnik/home/Downloads/
....

Both seem wrong, should always be
/home/user_name/Downloads
or in your case
/home/besnik/Downloads
-
P.S.
Pershendetje me shumic.

Are you installing Probe Basic or Basic Probe?
Not the same thing, and still remain very, very confusing.

How do I switch to QtPyVCP?

Hello,

I just installed my first Linux version on an old Thinkcentre i have laying around. Iam planning onbuilding a new CNC using LinuxCNC so I thought maybe I can and lear how to use it before i finish my CNC. Kinda just to get used to Linux.

So after like 2 hours I finally managed to get debian 12.10.0 running on my Thinkcentre. Then I started to follow the instructions on the LinuxCNC page.

I did the updates:
sudo apt-get update
sudo apt-get dist-upgrade

Then I installed the Preempt-RT kernel
sudo apt-get install linux-image-rt-amd64

everything worked fine. After the restart it selected the right linux RT version.

So the issue starts here.
 

If i click on the link for the linuxcnc-install.sh file it doesnt download anything. So where exactly do I get the script? Iam probably just to stupid to understand it.
Also chmod +x linuxcnc-install.sh doesnt work. I have even tried opening an txt.file and naming it linuxcnc.install.sh with the script from the browser. But still nothing.

Found another thread with simillar issue
$ chmod +x besnik/home/Downloads/linuxcnc-install.sh
Or better yet
$ cd besnik/home/Downloads/
$ chmod +x linuxcnc-install.sh

Always says No such file or directory.

Does anyone have an idea what I am missing I can already deel its something easy to fix I just dont see it. Kinda embarrassing asking for help

Python's stacktraces are not helpful.

I always miss Java's verbose and informative stacktraces whenever Python enters my life (generally via apt (which seems to have Python components) and LinuxCNC, which seems to have a lot of Python)

Perl might be the "duct tape of the internet", but Python is definitely the duct tape of GNU/Linux.

Perhaps chmod -R 777 user_tabs will fix it.

Otherwise I have literally no clue.

Moved to QtPyVCP section.

After installing and configuring Probe Basic I always get these errors, the user_tabs folder is present:
Traceback (most recent call last):
  File "/usr/bin/probe_basic", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/lib/python3/dist-packages/probe_basic/__init__.py", line 20, in main
    qtpyvcp.run_vcp(opts, VCP_CONFIG_FILE)
  File "/usr/lib/python3/dist-packages/qtpyvcp/__init__.py", line 26, in run_vcp
    run(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/qtpyvcp/app/__init__.py", line 129, in run
    launch_application(opts, config)
  File "/usr/lib/python3/dist-packages/qtpyvcp/app/launcher.py", line 78, in launch_application
    loadWindows(config)
  File "/usr/lib/python3/dist-packages/qtpyvcp/app/launcher.py", line 230, in loadWindows
    window = _initialize_object_from_dict(window_dict)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/qtpyvcp/app/launcher.py", line 210, in _initialize_object_from_dict
    return obj(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/probe_basic/probe_basic.py", line 53, in __init__
    self.load_user_tabs()
  File "/usr/lib/python3/dist-packages/probe_basic/probe_basic.py", line 87, in load_user_tabs
    user_tab_folders = os.listdir(user_tabs_path)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] Datei oder Verzeichnis nicht gefunden: 'user_tabs/             # REQUIRED Setting for Probe Basic'

Maybe someone can shed some light on the matter for me.

Normally we would not use hex files at all because the standard way to update
would be over serial. I will look into why the serial update fails.