Advanced Search

Hi Hakan
thanks for your help , I'm using the cia402pv component you put together, I can't seem to get the drive to feed back the velocity of the motor could this maybe be another issue ?

I seem to have made a mistake in the cia402pv component with the stat-at-speed pin..
I'll look at that tomorrow. If you just want to mill you can comment out the spindle-at-speed signal and
setp Spindle.0.at-speed 1
 

Hi everyone,I’ve recently finished mounting my machine to its base and tidying up the wiring, so I decided to try running a quick program to see if everything was working properly.Machine Configuration:

• Controller: Raspberry Pi 5
• Servos: 3 × Leadshine EL8 servo drives with 400 W motors (EtherCAT)
• Spindle: 1 kW StepperOnline drive (EtherCAT)

The program starts fine, but the machine seems to get stuck at the first G1 command.After doing some reading, it looks like this could be related to the “spindle-at-speed” signal in the HAL configuration.Because I’m using EtherCAT, I’m not sure where this needs to be handled:
Should the spindle-at-speed signal be configured in the HAL file, or Is it something that needs to be set up in the .comp file for the EtherCAT drive?

Any guidance or examples on how to handle this signal within an EtherCAT setup would be really appreciated. when the spindle is running currently I am having no feedback from the drive to record the actual speed ? 

PCW wrote:

Searching the forum for MPG will finds a number of MPG implementations and hal file examples.
 

Or you could've read the docs.
linuxcnc.org/docs/stable/html/examples/mpg.html
skip using the encoder and use the mesa MPG terminals

some examples form my machines, see on the right side a row of 3 relays, those are for inputs and they isolate the machine part from electronic part, so less interference and no need for good shielded cables (i can no find good cables here):
forum.linuxcnc.org/show-your-stuff/38547...uild?start=30#165873
Or the "arduino" relays as seen here
forum.linuxcnc.org/show-your-stuff/38547...ild?start=110#172157

tommylight wrote:

Found another one
blog.loriowar.com/how-to-reduce-jitter-on-linuxcnc

This one at least mentions network latency. In my view this is more important than system latency where you are not using software stepping.

That should work. It's a 16-bit encoder counter so be prepared to handle overflow.
TIM2/TIM5 are 32-bit so better to use that when you do your own. There is only one 32-bit though.
 

I added the following HAL code to the configuration of my mill to keep the spindle on for a few seconds after the spindle is disabled just to get the nice smooth ramp down you are looking for:

# --- timedelay before disable spindle output for deceleration ramp --- #
loadrt timedelay names=timedelay.spindle-enable-soft-stop
addf timedelay.spindle-enable-soft-stop servo-thread

setp timedelay.spindle-enable-soft-stop.on-delay 0
setp timedelay.spindle-enable-soft-stop.off-delay 3

net spindle-enable => timedelay.spindle-enable-soft-stop.in
net spindle-enable-soft-stop <= timedelay.spindle-enable-soft-stop.out
net spindle-enable-soft-stop => hm2_7i96s.0.7i84.0.0.output-01

For more information see my post here: forum.linuxcnc.org/12-milling/50559-opti...sion?start=70#309845

You have not said what voltage you are using.
The rationale behind 24 volts being more or less standard for industrial systems is that it is more resistant to triggering from noise because a much greater voltage fluctuation is required to trigger false readings.

I think you have already diagnosed the issue.
Also using an industrial power supply like a Meanwell MDR-60-24 won't break the bank. I have lost count of people reporting issues when they use 5 volt plug packs...

Thank you.

The encoder is not 1:1 to the ATC Carousel, but mounted directly on the carousel shaft.
The relation is more about 43:1but not exactly, I did a hack reprogramming of the carousel.comp, but not nice and maybe not that thought trough, needs to be tested.

If it does not work i will have a look on the counts mode and see if that will work better.

Hello
I bought the following card (still waiting for it) and it seems to have TIM8 CH1 and CH2 available
fr.aliexpress.com/item/1005008473184616....gatewayAdapt=glo2fra 

youre right about the bob, but for now i dont have a bob.
For now i'm new to mesa card in general.
Thanks

I have finally gotten my first LinuxCNC machine homing! It is a XXYZA machine. I am quite happy with my progress and everything I have learned. The machine appears to be holding tolerances well while jogging and I am very excited to start running gcode here shortly. 

However, I am getting an oddity with my home switches while homing. It's a low voltage system for signals and having spent a lot more time with all of this I realize that a 12 or 24 volt communication voltage and some daughter cards would have kept some of my troubles in the realm of programming and less in the realm of electrical engineering. I have a 6i25 running to a bank of CL86Y's and 4 functioning home switches (XYZA) from 0V to GPIO pins that are normally closed, one for each axis. I think I am making some sort of pullup/pulldown or other fundamental signal error in my home switches.

With my attached hal/ini configs while homing if I start with switches depressed everything homes great. X and A homing are disabled while I am playing with settings but they work when enabled. Halshow shows my switches working as expected. Diag goes "yellow" when the switch is hit and resumes "red" when released. Sometimes I have seen an unexpected flicker, and the shielded wire is not yet grounded. All other cables are shielded and grounded so I think EMI is minimal, but I will be grounding the shield shortly regardless. However, if I start off of switches the axis will pulse forward and then stop after a move of no even length and throw an error about not being on a switch when backing up, as if it was transitioning from search_vel to latch_vel.

I don't mind starting the machine homing by hand, but I am concerned my home switches are triggering the 6i25 IO while I would be normally operating. This seems like it cannot be a great thing to be doing, but maybe it would not be relevant. 

If you have any suggestions to get more reliable performance, I would appreciate leaning on all of your experience. 

Warning: I have a machine with a 12-core Intel i7 (numbered 0 to 11). The numbers shown in this answer will vary depending on the number of cores in each machine. Do not use Ctrl+C/Ctrl+V. You must read the articles cited in the thread. The calculations for the numbers are there.

Ladies and gentlemen, this looks promising!

It seems that POSIX realtime (PREEMPT_RT kernels) is finally working decently.

This is my machine (linuxcnc info):

The file:    /tmp/linuxcnc_info.txt
can be posted to a forum or a web site like:
     pastebin.com
in order to provide information about the linuxcnc
system and configuration.

VIEWER=kate
                Date: sáb 29 nov 2025 19:36:45 CET
            UTC Date: sáb 29 nov 2025 18:36:45 UTC
        this program: /home/xiuser/linuxcnc/scripts/linuxcnc_info
              uptime:  19:36:45 up  1:04,  1 user,  load average: 0,35, 0,50, 0,79
      lsb_release -a: Distributor ID:    Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:    12
Codename:    bookworm
            linuxcnc: /home/xiuser/linuxcnc/scripts/linuxcnc
                 pwd: /home/xiuser
                USER: xiuser
             LOGNAME: xiuser
                HOME: /home/xiuser
              EDITOR: 
              VISUAL: 
            LANGUAGE: 
                TERM: xterm-256color
           COLORTERM: truecolor
             DISPLAY: :0.0
             DESKTOP: lightdm-xsession
        display size:     3360x1080 pixels (889x285 millimeters)
                PATH: /home/xiuser/linuxcnc/scripts:/home/xiuser/linuxcnc/bin:/home/xiuser/.local/bin:/home/xiuser/linuxcnc/bin:/home/xiuser/linuxcnc/scripts:/home/xiuser/linuxcnc/tcl:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

uname items:
         nodename -n: HPi7
      kernel-name -s: Linux
      kernel-vers -v: #1 SMP PREEMPT_RT Debian 6.12.57-1~bpo12+1 (2025-11-17)
          machine -m: x86_64
        processor -p: unknown
         platform -i: unknown
      oper system -o: GNU/Linux

/proc items:
             cmdline: BOOT_IMAGE=/boot/vmlinuz-6.12.57+deb12-rt-amd64 root=UUID=6dec6435-2cb8-427a-9697-c8d82ce45bdb ro net.ifnames=0 skew_tick=1 nosmt=force kthread_cpus=0-5 irqaffinity=0-5 rcu_nocb_poll rcu_nocbs=6-11 nohz=on nohz_full=6-11 isolcpus=6-11 intel_pstate=disable amd_pstate=disable idle=poll cpufreq.off=1 cpuidle.off=1 intel_idle.max_cstate=0 amd_idle.max_cstate=0 nowatchdog nosoftlockup i915.force_probe=!4680 xe.force_probe=4680
          model name:  12th Gen Intel(R) Core(TM) i7-12700
               cores:  12
             cpu MHz:  3685.961
             parport: 
              serial: 

Versions:
                 gcc: gcc (Debian 12.2.0-14+deb12u1) 12.2.0
              python: Python 3.11.2
                 git: git version 2.39.5
          git commit: 2cee0486b4
                 tcl: 8.6
                  tk: 8.6
               glade: glade 3.40.0

linuxcnc_var all:

     LINUXCNCVERSION: 2.10.0~pre0
LINUXCNC_AUX_GLADEVCP: /usr/share/linuxcnc/aux_gladevcp
LINUXCNC_AUX_EXAMPLES: /usr/share/linuxcnc/aux_examples
            REALTIME: /home/xiuser/linuxcnc/scripts/realtime
                 RTS: uspace
          HALLIB_DIR: /home/xiuser/linuxcnc/lib/hallib
              PYTHON: /usr/bin/python3.11

This is the latency histogram before tuning:

 

And this is the histogram after the changes...

 

First change: A new kernel that includes the new Intel Xe video driver, which will replace the venerable i915. Xe is in kernels >= 6.12.

kernel-vers -v: #1 SMP PREEMPT_RT Debian 6.12.57-1~bpo12+1 (2025-11-17)

Second change: the GRUB_CMDLINE_LINUX_DEFAULT boot line in Grub. Now cmdline is:

cmdline: BOOT_IMAGE=/boot/vmlinuz-6.12.57+deb12-rt-amd64 root=UUID=6dec6435-2cb8-427a-9697-c8d82ce45bdb ro net.ifnames=0 skew_tick=1 nosmt=force kthread_cpus=0-5 irqaffinity=0-5 rcu_nocb_poll rcu_nocbs=6-11 nohz=on nohz_full=6-11 isolcpus=6-11 intel_pstate=disable amd_pstate=disable idle=poll cpufreq.off=1 cpuidle.off=1 intel_idle.max_cstate=0 amd_idle.max_cstate=0 nowatchdog nosoftlockup i915.force_probe=!4680 xe.force_probe=4680

Note: force_probe => i915 OFF and Xe ON. My video device ID is 4680. Yours may be different. lspci gives the ID for each machine.

Third change: Modifying kernel parameters at runtime:

sudo sysctl kernel.timer_migration=0
sudo sysctl kernel.sched_rt_runtime_us=-1

 

Aha. Many thanks - commenting out that duplicated line did the trick, so I now have the machine moving in closed loop, homing correctly and e-stopping safely. That's a great step forward and it feels as if I'm getting close to getting this sorted out.

I now have to get the xhc-whb04b-6 MPG connected up (currently commented out) and the spindle vfd doesn't respond, so I'll need to check that out too.

Andy Pugh's macros don't show up in my GUI. I have the tab showing up but clicking on it does nothing - none of the graphics appear. There are several gmoccapy lathe sims that work but something's not right in my setup. Again, I'm not clear what files need to be where and what configs need to be set up. Is there any documentation for the lathe macros that I can refer to?

Many thanks