Advanced Search

Mesa is definitely the way to go. It "future proofs" your setup. Swapping machines is easy, latency is less of an issue. If your current machine goes "poof" getting back & running is a simple task.

Tho it really depends on your budget....shipping to the Southern Hemisphere is brutal.

The easiest way, to prevent a total rewire is grab a 7i92T and that can plug into your existing parallel port breakout boards (or more correctly the breakout boards cab plug into the 7i92T). That'll get you going, later if you really feel the need a 7i76 can be plugged into the 7i92T.

I'm running a 7i92,7i76, another card for extra Smart Serial ports an analog smart serial card for the spindle and a 7i73 for the pendant.......Hasn't missed a beat in all the years I've been using them. Worked fine on the dual core J3355B system I used for a bit. Asrock J3355B-ITX. Upgraded to a system with a smaller foot print

Regarding isolating cores, from the dark spells I've read it would seem to isolate the cores on the same die, well that was the recommendations for Intel.

Man I definetly need to take some sleep....

 

It definetly did something this time. Thanks for youre help guys. I was ready to just go back to Estlcam and windows haha.

If I go to Applications -> CNC there are only two options there is Documentation and G-Code Quick Reference. There is no LinuxCNC application does that mean somthing went wrong with the installation? I did a restart same thing.

 

Hallo Joe,
ich bin aus München und habe auch ein 4060 mit Parellelport. Wäre sehr interessiert für so ein Treffen. Auch privat zum Austausch, wenn du Interesse hast kannst du mich anschreiben.

Gruß Jerry

Hi Todd,

Thanks for your response — I’ll definitely give that a try, as it feels like my last resort with this current setup.

I've already disabled everything I possibly could in the BIOS. The only things I haven't touched yet are the memory timings and voltages. If this doesn’t work either, I’m honestly not sure what else is left to tweak.

I'm also considering switching to a Mesa card, possibly the 7i76EU, but I have zero experience with Mesa hardware. I’ll need to figure out whether it will work with my three DM542A stepper drivers, and also with my VFD, which is currently controlled over USB using: `loadusr -Wn vfd hy_vfd -n vfd -d /dev/ttyUSB0 -p none -r 9600`

Things i disabled next to the obvious, like settings for fixed clock speeds (fclock 1066, bclock 1000) disabling power management and disabling hardware that is not being used (BT, Wireless, serial, audio, fancontrol (disabled fixed on 100%)):

BIOS Settings (set to Disabled):

SMT / Hyperthreading
→ Disables logical cores to reduce cache sharing and latency spikes

C1E, C6, and other C-States
→ Prevents the CPU from entering sleep states, ensuring consistent timing

Streaming Stores Control
→ Avoids aggressive memory write optimizations that can disrupt real-time behavior

DRAM Scrub Time
→ Turns off background memory error checking to avoid unexpected memory bus usage

GMI Encryption Control
→ Disables inter-chiplet encryption on Infinity Fabric to reduce overhead and latency

XGMI TXEQ Mode
→ Prevents signal equalization tuning that could introduce instability or variability

DRAM Map Intervention
→ Disables memory remapping logic that can introduce unpredictable latency

DF Sync Flood Propagation
→ Prevents error broadcasts across chiplets, reducing the chance of system-wide stalls

   

 

home and besnik are in the wrong places again and Downloads starts with upper case D. Linux is case sensitive so D and d are not the same.
Copy and paste from here:

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