Unable to cut correct thread with G76

Patrik T wrote: You are not listening to me saying it is software because you made up your mind that is is hardware..

The difference is that we can _all_ look at the software and verify that it uses spindle position from HAL.

One case where things might go wrong with a varying-speed spindle is if the Z-axis acceleration rate is set two low to follow the changes in spindle speed. For threading you do want the Z accel to be pretty close to the physical limit.

Yes, and when the spindle speed varies faster than the Z-axis is allowed to accelerate there will be a minor dent in the thread if the algorithm keeps track of the spindle's absolute position and syncs the tool to that.
If the algorithm does not sync to the spindle absolute position the errors will accumulate and produce a bad thread.

Many thanks for the replies.

After days of investigation the problem was found in the timing belt drive setup used between the spindle and encoder:
The pulleys were not exactly the same size, despite original statement of shop owner. After matching the size of pulleys the thread cuts are PERFECT. We could go even for 1200 RPM without quality loss. So the G76 and G33 work very well, thank you again for the great software and hardware (Mesa 7i90).


.

Patrick T, did you ever resolve this? I have the same issue... cuts 3 or 4 spot on then loses the index, then finds it again. Everyone says noise and pulse issue... but I believe there is something wrong with Linuxcnc under G76... especially when it can't keep the trajectory velocity.

cadcam, no, I did not resolve it.
I am not sure what you are describing is the same issue I have. See the attached photo, this is what happens for me.

The left thread is G76, you see at the root of the thread that consecutive cuts do not sync the same so there are multiple "roots". The right thread is another algorithm where the sync stays good and the root is cut in the same place every cut.

How did you change the algorithm? (And where?)

Thanks Patrick,

Yeah, it's a similar issue with multiple roots that run parallel to each other. I don't believe it's a backlash issue either.

Oh, it does look the same for you.
I have some backlash in that lathe but both threads in the picture are cut in the same lathe and with the same setup.

I did not change the G76 algorithm. I have a separate code for moving and syncing the tool in my Xbox pendant implementation.
This code uses the same spindle encoder signal, but jog counts to sync the tool to the spindle absolute position.

Patrik T wrote: I did not change the G76 algorithm. I have a separate code for moving and syncing the tool in my Xbox pendant implementation.
This code uses the same spindle encoder signal, but jog counts to sync the tool to the spindle absolute position.

That really shouldn't be better. In fact it ought to be far worse as the position commands are passing through non-realtime layers and USB!

Does your lathe have a spindle-at-speed signal? Are you threading in CSS mode?
Is this a servo or stepper machine?

I am not using the very slow halui. I am using the 1000 Hz servo thread, which apparently is fast enough to make fine threads. An RT thread would maybe be a further advantage, but I did not need it. The proof is in the pudding.

The USB is not involved in the actual syncing, so that is not an issue.

I have no spindle at speed and I did not use CSS.
It is a stepper so it is possible that I am losing steps, but why would I only lose steps when using G76.
Edit: Also, the thread appearance is not consistent with what I would expect if it was a losing steps issue.