Advanced Search

You had the directory tree order wrong. You typed "cd home/besnik/downloads/" and it needs to be "cd besnik/home/Downloads/". Also Linux is case sensitive so the capitol leter "D" is also important.

Keep playing with different combinations of cores isolated using isolcpus till you find what gives you the best result. Your Ryzen has 6 of them to choose from, I'd test different combinations of 1, 2, and 3 cores isolated, like 1,3,5 or 3,4,5 or 0,1,2, or 4,5, or 0,1...

I'm very new to LinuxCNC, and using a CNC machine custom built and configured by someone else. Running into some errors that none of us could figure out, help would be very very appreciated.

We are using cia402 and ethercat to run a 9-axis system, including xyz and 6 rotation axis. We noticed that the actual and commanded positions of the xyz axes are always off by a factor of 80 , e.g. if we send the Gcode to move X axis by 10mm, it moves by 10mm, the commanded position is 10, but the 'actual position' is 0.125. We can still run .ngc files, they do exactly what we expect them to do, but at the end we get motor position error on these three axes.

We've tried increasing the FERROR and MIN_FERROR in the .ini file

...

[AXIS_X]
MIN_LIMIT         = -5
MAX_LIMIT         = 395
MAX_VELOCITY         = 500
MAX_ACCELERATION     = 250

[JOINT_0]
TYPE             = LINEAR
MAX_VELOCITY         = 500
MAX_ACCELERATION     = 250
FERROR             = 200
MIN_FERROR         = 50
MIN_LIMIT         = -1
MAX_LIMIT         = 1200
HOME            = 0
HOME_OFFSET        = 0
HOME_SEQUENCE        = 1
HOME_IGNORE_LIMITS    = YES
# nach github.com/dbraun1981/hal-cia402/blob/main/README.md

HOME_SEARCH_VEL     = 5.0
HOME_LATCH_VEL         = -2
HOME_FINAL_VEL        = 1
HOME_USE_INDEX    = FALSE

...
 .hal:

loadrt [KINS]KINEMATICS
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS

loadusr -W lcec_conf ECOMODUL_ethercat_conf.xml
loadrt lcec
loadrt cia402 count=9

###########################################################
# Functions servo-thread
###########################################################

addf lcec.read-all servo-thread
addf cia402.0.read-all servo-thread
addf cia402.1.read-all servo-thread
addf cia402.2.read-all servo-thread
 ...

addf motion-command-handler servo-thread
addf motion-controller servo-thread #########################################
#nets
#########################################
net emc-enable => iocontrol.0.emc-enable-in
sets emc-enable 1 #config
#testing Werte für pos-scale fehlen
#x
setp cia402.0.csp-mode 1
setp cia402.0.pos-scale 8000
#y
setp cia402.1.csp-mode 1
setp cia402.1.pos-scale 8000 
#z
setp cia402.2.csp-mode 1
setp cia402.2.pos-scale 8000 ...

#from servo(ethercat) to cia402 net x-statusword      lcec.0.8Axis.xcia-statusword => cia402.0.statusword
net x-opmode-display  lcec.0.8Axis.xopmode-display => cia402.0.opmode-display
net x-drv-act-pos     lcec.0.8Axis.xactual-position => cia402.0.drv-actual-position net y-statusword      lcec.0.8Axis.ycia-statusword => cia402.1.statusword
net y-opmode-display  lcec.0.8Axis.yopmode-display => cia402.1.opmode-display
net y-drv-act-pos     lcec.0.8Axis.yactual-position => cia402.1.drv-actual-position  net z-statusword      lcec.0.8Axis.zcia-statusword => cia402.2.statusword
net z-opmode-display  lcec.0.8Axis.zopmode-display => cia402.2.opmode-display
net z-drv-act-pos     lcec.0.8Axis.zactual-position => cia402.2.drv-actual-position

...
#from cia402 to servo(ethercat) net x-controlword         cia402.0.controlword     => lcec.0.8Axis.xcia-controlword
net x-modes-of-operation  cia402.0.opmode     => lcec.0.8Axis.xopmode
net x-drv-target-pos      cia402.0.drv-target-position   => lcec.0.8Axis.xtarget-position net y-controlword         cia402.1.controlword     => lcec.0.8Axis.ycia-controlword
net y-modes-of-operation  cia402.1.opmode     => lcec.0.8Axis.yopmode
net y-drv-target-pos      cia402.1.drv-target-position   => lcec.0.8Axis.ytarget-position net z-controlword         cia402.2.controlword     => lcec.0.8Axis.zcia-controlword
net z-modes-of-operation  cia402.2.opmode     => lcec.0.8Axis.zopmode
net z-drv-target-pos      cia402.2.drv-target-position   => lcec.0.8Axis.ztarget-position

...
#from motion to cia
net x-enable    <= joint.0.amp-enable-out => cia402.0.enable
net x-amp-fault => joint.0.amp-fault-in   <= cia402.0.drv-fault
net x-pos-cmd   <= joint.0.motor-pos-cmd  => cia402.0.pos-cmd
net x-pos-fb    => joint.0.motor-pos-fb   <= cia402.0.pos-fb net y-enable    <= joint.1.amp-enable-out => cia402.1.enable
net y-amp-fault => joint.1.amp-fault-in   <= cia402.1.drv-fault
net y-pos-cmd   <= joint.1.motor-pos-cmd  => cia402.1.pos-cmd
net y-pos-fb    => joint.1.motor-pos-fb   <= cia402.1.pos-fb net z-enable    <= joint.2.amp-enable-out => cia402.2.enable
net z-amp-fault => joint.2.amp-fault-in   <= cia402.2.drv-fault
net z-pos-cmd   <= joint.2.motor-pos-cmd  => cia402.2.pos-cmd
net z-pos-fb    => joint.2.motor-pos-fb   <= cia402.2.pos-fb

Okay thats a good tip that thoose commands are wrong. I found thoose commands on the forum.I tried the commands with the order you told. But I still get the same error. I took some pics maybe they help. 

 

 

Thanks for trying to help me

- Shume flm per ndhime

Hello all. I've got an odd problem with ohmic probing that recently cropped up.

When I tap the Ohmic Probe button in QtPlasmaC, probing immediately aborts without moving the Z axis. Normally I would assume that the ohmic sensing circuit is always closed for some reason, but it's definitely not that.

halscope shows that the ohmic sense feedback pin is never activated. The ohmic enable pin is however correctly activated.

I've verified that the relay on my breakout board closes when ohmic probing is activated. If I connect the ohmic sense wire directly to the table, probing again immediately aborts and the ohmic sense pin is correctly activated. I've also verified that the relay that closes when the sense circuit is closed is not activated. 

Z axis is homed. It correctly probes when using only the float switch.

So my question is: what can cause a situation where ohmic probing aborts no matter if the sense pin is active or not?

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?