Threading Index Varies With Speed

As far as I understand it, ideally there should be no offset.
The offset is there because the algorithm only matches velocity
and does not do the calculations needed to match velocity
_and_ correct position.

After pulling my hair out trying to figure out why G33.1 wasn't working on my lathe while attempting to test the problem raised in this thread, @cmorely pointed out I'm having the same issue.

forum.linuxcnc.org/38-general-linuxcnc-q...pping-problem#319786

So I can confirm spindle synchronization start points vary with spindle speed in G33.1 as well as G76 - and it's way worse on my lathe than the OP reported on his.

In my case a difference of 140rpm (60 vs 200) resulted in appx 0.750" difference between the Z-start point when synchronization kicked in on a 1/20 pitch (0.050").

According the the formula Andy posted earlier, my Z-axis requires the following distance to get up to speed

 

I don't understand why there is such a significant difference between what I'm seeing and what the OP's lathe is doing.

Unless somone has other thoughts, I think this is a bug.

Update here:
forum.linuxcnc.org/38-general-linuxcnc-q...blem?start=10#319865

So my lathe's behavior is closer to the OP's when running a program vs. MDI.

But as I mentioned in the other thread, I don't think this behavior is correct even with the reduced 'dive' towards the synch point.

I was able to reproduce this error with a simple test setup
with no mechanics and using g76. It also causes errors even
at a constant spindle speed, as the offset changes with thread
depth over the multiple threading passes which would cause
a  wider than expected cut.

To test this I setup a 7I96S with a stepgen spindle setup to
emulate a 8 count encoder with index (using the stepgen table mode)

I checked the offset by using the sum2 component to scale the spindle
rotations to the thread pitch and subtract the result. This offset
should be independent of spindle speed, X,Z motion constraints
and drive line distance to thread pass, but it is not.

Have you raised an issue on the LinuxCNC github page?
 

Have you raised an issue on the LinuxCNC github page?

While I've raised a couple issues in the past, I am reluctant to directly engage on GH because I don't speak 'computer' fluently.  I can describe an issue in laymans terms, but as soon as any discussion moves towards code-type testing & solutions I'm lost.  My typical modus operandi is to prompt enough discussion on this forum that somone clever takes up the torch over on GH.

I'll raise one now, thanks for the reminder about it.

EDIT: github.com/LinuxCNC/linuxcnc/issues/3455

PCW wrote:

It also causes errors even
at a constant spindle speed, as the offset changes with thread
depth over the multiple threading passes 
 

Which LinuxCNC version? Not being able to cut threads would be a huge problem. 

In your constant speed example, is there any possibility that what you are seeing is the "virtual compound angle" Q ?

Yes, you are right, there is no error on multiple constant speed
paths, I had neglected to 0 the q parameter when testing.
This is because the return path has a constant x distance from
the cutting path.

You get the error if you change the spindle speed (or motion constraints)

Basically I would think the the z motion should be strictly geared to
the spindle (+- any deliberate offsets like "q") just like a mechanical
lathe.

Are you using position-interpolated with your 8-count encoder?
Is there any quantisation of the error you see?
I haven't looked at the spindle synch code, but if it tries to "start early" before the index then possibly a low-count encoder will make that more difficult.

Yes, I am using interpolated position (which is very precise with the hardware generated "encoder' signals)
 

Yes, the X movement (joint 0 in the plot) is done before index is detected
but the interpolated position (spindle-revs) removes any quantization
issues: