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?

Thanks, but that does not prove to me that it is keeping track of the spindle's absolute position.
I am doing a small M5 thread. The lower M5 pitch makes a small pitch error more apparent than it would be on the big thread in the video..
I think the pitch error also only appears if the spindle speed varies rapidly.

No, I have not verified that the encoder does not lose counts.
I don't think it does since it works in another algorithm.

G33 and G76 use spindle position sync, not velocity,
if you have threading issues its most likely a hardware or setup issue

This is what happens when two people used to being right meet
I am not listening to you saying it is hardware because I have made up my mind that it is software.
You are not listening to me saying it is software because you made up your mind that is is hardware.
We can agree that we disagree.

Let's maybe give the thread back to the OP.
Thanks for the chat.

I have not made up my mind either way (and there are some known bugs in G76 in some LinuxCNC versions),
I just know that G76 and G33 use position mode spindle synchronization and that many people cut fine and long threads without issue with LinuxCNCs G76 so it just seems more likely the problem is something specific to his setup