Advanced Search

Mesa 7I95T has been SOLD, the rest is still available.

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.

@tuxcnc
I deleted your post, you wrote a full page with useless info and failed to reply to the question asked by OP.
That will not be tolerated any more.
Keep your replies to the subject as much as possible.

Holzwurm56 wrote:

Hello,
When using a parallel port, entering the jitter value in Stepconf results in the calculation of the maximum step rate. Does this figure—for example, 33333 Hz—apply to each axis individually, or to all axes combined?

For each pin, parallel port so all pins can be controlled in parallel or at the same time.

I am pretty sure QtPlasmaC already has that implemented and working.

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 an 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.