Threading Index Varies With Speed

I think that there is actually a warning about this in the docs.
(Actually it warns of something slightly different, linuxcnc.org/docs/stable/html/gcode/g-code.html#gcode:g76 )

At the beginning of the pass the Z axis is stationary. It sees the index pulse, and then has to "chase" the spindle-synch point.
If the axis acceleration is limited, then I can see that it might have trouble catching up.

What is your Z accel limit? Given that, what distance does the spondle need to catch up to a 100rpm spindle? (v^2 = 2as )

These are some great questions. I spent some time collecting information to address them.

cakeslob question: I ran the 1"-8 scratch threads again. I tried hand turning the spindle, then ran it at 100, 150, and 200 RPM. I found the following:
1) Yes, you can run the threading G-code and cut the thread by turning the spindle by hand
2) The hand turned scratch wobbles a bit compared to the ones at set speeds
3) The hand turned scratch is the leftmost one in the photo, then the 100 RPM to its right, then the 150 and the rightmost thread at 200 RPM.
4) The spacing of the scratches, measured as best as I can from the hand turned scratch line, is
     a) 0-100RPM -0.025"
     b) 0-150 RPM -0.055"
     c) 0-200 RPM -0.085"

This supports andypugh's comment about the Y axis having to catch up the position after it detects the index pulse. The faster the speed, the more the thread falls behind the desired position.

PCW question:
I've attached my INI and HAL files.


Here's the section for the Z axis



I used HALSCOPE and watched hm2_7i92.0.gpio.014.in_not (spindle index) and hm2_7i92.0.gpio.016.in (spindle A). That was working as expected, as I got one index pulse per 10 "A" pulses.


I then watched the spindle index and hm2_7i92.0.stepgen.02.position-1b (Z axis position) while running the threading program.

For 100 RPM:


For 200 RPM:


This looks to me like it's working as expected, where the falling index pulse begins the carriage Z movement. Note that I have steppers and this is not a real feedback signal on the position..That leads me to believe that LincxCNC is working correctly and that my problem is a physical one with my lathe.

M4MazakUser question:
Yes, both the index and "A" spindle signals are driven directly off the spindle.

andypugh question:
I'm using the threading program from the O-code section of the forum (and which I wrote). Before issuing the G76 code, the program moves the tool to the starting X and Z position. I think that there's validity to your comment about the axis acceleration perhaps affecting the spindle synch point.  I'm not sure what to do about it, though. The carriage on my lathe probably weighs nearly 100 lbs, and the stepper motor is probably undersized. I've had to limit my Z acceleration to 2 i/s^2, or it loses steps.

I ran the calcs you suggested (v = sqrt(2as)) for the 8 tpi thread I'm trying to cut. For the final velocity, I need to cut 1/8" per revolution at the set RPM.
For 100 RPM, v = 100 r/m / 60 s/m / 8 r/i = 0.208 i/s
And the distance to reach that speed s = v^2 / 2a, or 0.208^2 / (2 * 2) = 0.011"
For 200 RPM, s = 0.043"

The takeaway here is that the calculated distance is exponential with speed. When I measured the scratch marks from the hand turned (very slow RPM) values I got 0-100 RPM was 0.25" and 0-200 RPM was 0.085", which is exponential behavior. They're also about twice the values calculated in the formula.


So, I'm still not sure there's a path forward to correct this. A larger stepper, able to accelerate the heavy carriage would likely help, in that I could increase the maximum acceleration. But I'm not losing steps, so the program should be able to handle this. Perhaps a servo motor with closed loop control would fix it.

Your attachments did not seem to get attached...

setp hm2_7i92.0.packet-read-timeout 30

I would set this to 80 ( 80% = 800 usec at a 1 ms servo
thread period), or just comment it out
If you are dropping many packets, that might
be an issue.

Loss of steps might be an issue also. This may be improved
by using the interpolated encoder position, as a 10 count
per turn encoder is going to give a very rough Z axis position
command, only smoothed by the acceleration limits.

The Z motion plots look linear so the main error seems to be a variable offset
at the start. Are multiple passes at the same speed perfectly aligned?
The start and end of motion use maximum acceleration so  possible
locations of lost steps.

Removed setp from HAL file and retested. No change in observed behavior.

Yes, multiple passes at same speed are perfectly aligned with previous passes. This is true even when machine is turned off overnight and turned on next day (and re-homed). I don't think I'm losing pulses in the stepper motor. You can usually hear the motor miss pulses, and the results are reproducible.

10 count per turn encoder results in delta Y per pulse of 0.0125" for 8 TPI. Seems like the error would be less that that, and I'm seeing 0.085" error at 200 RPM.

Looking at your pictures again, and they don't make sense...

The time between index pulses is ~1.2 seconds in both pictures = ~50 RPM

100 RPM would be 0.6 seconds per index, 200 would be 0.3