Unable to cut correct thread with G76

Hi All,

An older manual lathe has been converted to CNC. Vexta 5 phases stepper motors are both on X and Z axis. All operations work as expected, but with thread cutting I have troubles. The NGCGUI G76 subroutine is from this forum created by BigJohnT.

The second pass of thread or any later one is started not in the right place (time), making the thread totally unusable.

The spindle is driven by VFD and the speed controlled with potentiometer. 400RPM is used most of the times for threading.
This speed seems pretty stable, because the same value measured by external meter and the spindle attached encoder. The encoder is set for 400ppr. The actual encoder was installed recently, but with another one everything looked similarly. No significant backlash on Z axis (less than 0.07mm).

The latest tries were made with G33. Just a simple G33 K, X repeated several times, and the mistaken start of thread entry is still there.
When I tried to chase the reasons I made a HAL scope measure of encoder A,B, Index values, and to my surprise the A/B signals are not evenly distributed (see attached images). It may have no any impact on wrong thread cuts at all, because G76/G33 wait for encoder index, but anyway it is strange for me.

Any ideas, hints are much appreciated to investigate the root cause of the issue.
If it helps of course I can attach the HAL file or the code used.

Janos

The A/B signals on halscope will not be an accurate representation of the input signals unless the
spindle speed is quite low (due to halscopes 1 ms sampling rate of the inputs)

If you get thread starts in the wrong place, it may be that you have a noise issue
(perhaps from the VFD) causing false index detection so as a first step I would make sure that

hm2_7i90.0.encoder.00.filter = 1
(this sets the encoder input filter to require 15 samples to detect a signal instead of the default 3)

and if that does not help by itself, lower the encoder sample rate to say 1 MHz:

setp hm2_7i90.0.encoder.sample-frequency 1000000

The combination of these settings allows the encoder to reject noise pulses shorter than 15 usec

I have also seen some issues with G76.
For me the start of the thread is OK, but my spindle speed varies due to its smallness and weak motor, the G76 does a poor job of keeping the pitch. This yields a thread that gets progressively more messed up each pass and farther along the thread..
My encoder signal quality is not great either and at first I thought it was beyond the lathe's capability to do good threads.

However, when I use my own spindle sync of the Xbox manual pendant software the threads are fine.
I was going to post pictures but my phone camera cannot zoom well enough. I have a friend with a small USB microscope that I can borrow later.

Patrik

If your encoder does not count correctly you cannot get good threads, speed variations
should not make a thread pitch error since the z motion is synchronized to the spindle.
I would verify that you are not losing/gaining counts as this will ruin threading

very low resolution encoders (a 1 to a few count/turn) will not handle speed variations as well

Thanks, yes, I understand that a bad spindle encoder would make threading impossible.
What I am saying is that it works fine with my homemade spindle sync algorithm but not with G76.

Just trying to help by pointing to this bug in a thread that addresses G76 problems.
I think the problem would be less noticeable on a lathe with a higher inertia spindle chuck, that is why it has not been apparent before. Still, someone might want to fix the bug.

I bet the problem is that G76 uses sync in velocity mode and does not keep track of spindle absolute position.

its is position mode:



Have you verified that your encoder is not losing/gaining counts?