Threading Index Varies With Speed

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.