Beckhoff EL5001-0012

I think the issue is that you are not using the feedback from the same encoder that's generating
the index. In this case, homing to index cannot work.

I'm certainly open to being educated here but I was reasonably convinced by what I was seeing. Have a look at my notes and perhaps you can see where / if I may have misunderstood what was happening:
www.murraye.com/2026/08/improving-homing...acy-on-linuxcnc.html

In my case, with 5um resolution scales and closed loop controls, my final resting position after homing can't be any more accurate than the resolution of the scales allow, so perhaps I've been chasing up a dead end anyway? A positional accuracy of 5 or 10um from true is probably the best I could hope for on a good day.

The PID element was initially due to my controllers being unstable but the homing velocity did seem to impact accuracy too.

Many thanks for your response.

I have found that 7.x kernels are better than 6.s kernels jitter wise.

It sounds like you are not using the index hardware at all.
There should be no effect of LinuxCNC timing or PID tuning
on the index position homing precision, if the index hardware is
actually used.

That is, the precision of position capture at the index position is
independent of the motion accuracy, though of course motion accuracy
after the index position is captured _is_ dependent on PID etc.

Hello everyone,
I am looking for available options to read and process a lathe spindle encoder over EtherCAT. For context, the spindle setup consists of an induction motor and a VFD controlled via RS485 or 0-10V.
Here is what I am currently considering:
• Beckhoff encoder modules.
• Mesa cards or other FPGAs. However, I would prefer a pure EtherCAT solution.
• CATIO-A IO board. It is not entirely clear to me whether it can fully support and handle a lathe spindle encoder.
• EtherCAT development boards. Are there any ready-made firmware options available for this specific task?
• Any other options?
I would appreciate any advice, experience, or recommendations you can share!


 

i have upgraded to trixie 6.12.113 kernel and jitter now is much worse..
Any updated instructions for improving jitter?
I think every kernel update make things worse.

For reference, here are some results showing a comparison between the original proximity switch homing and the "index gated" implementation.
 
The "optimisation" process produced the biggest improvements which were the result of finessing the PID values and slightly reducing the homing speed to minimise the delay between reading the index pulse and processing the data. Both methods were significantly improved this way but the end results were almost identical.
For the test setup, I repeatedly homed the machine (typically 20 times, as shown), with the absolute position automatically logged and plotted.

   I had seen the videos of that Tesla car on Youtube this past weekend. It's an interesting piece of window dressing 
to be sure, however the physics involved would say that other then showing off for investors it holds no practical use
nor do I really think you will ever see that on the road. That car can't hold batteries and enough fuel/Gas for propulsion
to be allowed by various departments of transportation. Purpose built aircraft still can fail and crash, you can imagine 
some idiot trying one of those stunts in traffic, a thruster fail, and crashing onto someone’s car killing them. That doesn't
include the fact that as soon as that car is airborne Aviation authorities will enforce there rules on it as well. You know
how much they complain about little johnny flying his little drone at a soccer field. How much more so with this.
will they sell a car that looks like the one they showcased? Probably. Will it do what was shown? Not Likely.
There's a big difference between a controlled environment and the open road.

In reality this is just more "Bread and Circus".

 
 

I've got a very similar setup on my lathe, and while that's not a milling machine, the setup has a lot in common.

I have a Chinese glass encoder on the Z axis and a magnetic encoder buried in the X axis (under the cross slide). The Z axis has an inductive (technically eddy current) proximity switch for homing and the X axis has a microswitch.

Those both work in closed loop. I don't use backlash compensation but the axes used NOS, Japanese ground ballscrews.

I spent several hours recently implementing "index mark" homing on both axes, using the synthesised encoder outputs from the servo drives and perhaps surprisingly there was no obvious benefit, so in the end I simply reverted to using the limit switches.

This is partly due to the way the index pulses are read by the 7i85, but then subsequently processed by Linuxcnc. I also suspect that some of the remaining variation is in the mechanism between the servo motors and the actual axis ie toothed belt, ballscrew, bearings, mechanical slop etc.

When you look at it that way, it doesn't seem obvious that moving the servo motor to a particular angular position after homing to the switch would necessarily deliver any obvious benefit. Either way, repeated testing with a decent DTI showed clearly that while the system was working, it didn't improve the homing repeatability or accuracy in my case.

This outcome may differ with your machine. Mine can only resolve / achieve 5um repeatability due to the encoder resolution and although I have good ballscrews and the machine is well adjusted, it wasn't built as a CNC machine, so is perhaps not the optimal choice.

Hi
I have been trying to understand what causes this issue with QTDragon UI running LinuxCNC 2.10 pre release. 
The issue is, almost always, the Z position seem to be wrong after i enable auto tool measurement.

This is what I usually do:
1. Enter the block height. I either measure this manually or utilize the 'Work Piece Height Probing' mentioned in 14.1 of the manual. This is given in the probe section.
2. I have setup the tool sensor at a given X/Y with search velocity, etc. I have also modified the tool change command to trigger the python plugin which does an automatic tool height measurement with this sensor. The height of the tool sensor is also fixed and given. This is provided in the probe section.
3. Load the gcode program and start. 

It correctly triggers the tool measurement and continues, but almost always the Z height is wrong. What is shown for G54 is unrelatable to the real Z height which should be there for the program. 

Is there anything that I am doing wrong? Do I have to set things up differently when I generate the gcode from Fusion 360? Also I see that some f the parameters like block height, tool height need to be specified in many places of the GUI. Which one is used by the auto tool measurement?

Thanks
Sus

Thanks for the help!
Actually, ChatGPT helped me find an error in the INI file for my closed-loop system (which I attached earlier).
There is a line for initial settings: `RS274NGC_STARTUP_CODE = G21 G40 G90 G94 G97 G64 P0.025`. By adjusting the `P` value within the `G64` command, you can fine-tune the surface quality. I achieved the best surface quality with `P0.005`. I haven’t tried your firmware, as I’m currently satisfied with the surface quality I’m getting. Thanks again for your help!