Threading Index Varies With Speed

 I'm having an odd problem. I'm running a threading routine using G76. I thought that, while threading, I could change the spindle speed without affecting the operation. Everything seemed to be working fine until I starting threading something a little larger for me - a 1"-8. I started to see bad gouging off and on during the threading. that at times nearly stopped the (7HP) lathe. I was only taking off about 0.002" per pass for most of the operation. I thought something must be moving, and checked all the obvious things. Everything looked OK.

One of the things I tried was making a scratch pass at three different speeds, 100, 150 and 200 RPM. I ran the same program each time without changing the setup. You can see that the cut indexed to a different point for each speed. Conversely, if I ran it three times at the same speed, it would index to the same cut.



This is not good! It means if I cut a thread and then need to recut it, I need to make sure that the spindle speed is exactly the same or I'll get a different thread position. Needing to cut the thread again can be because the piece rotated in the chuck during the cut or I didn't set the tool X position deep enough. I'm also thinking that as the lathe slows down slightly, it might change the Y position of the tool incorrectly and cause the gouging.

Any ideas?

Two indexing signals to LinuxCNC: one pulse per revolution for indexing, and ten pulses per revolution for position
Spindle speed set manually, and not by LinuxCNC
LinuxCNC v2.9.3

It's certainly supposed to be speed independent,
that is, the Z motion is supposed to be "geared" to the
spindle rotation.

(there's a video I can't find at the moment that shows
LinuxCNC threading while hand turning the spindle)

Possibly an encoder/index/Z axis issue?

You are correct, you can do this experiment by hand turning the spindle, and the Z axis will advance. I have not done this against the cuts at various speeds in the picture, so I don't know where the hand turned cut would be.

The behavior is exactly reproducible at the different speeds. That is, if you thread at 100 RPM and then run the program again at 100 RPM, it will cut the exact same thread. If you cut at 100, then at 150, and then back at 100 RPM again, the two 100 RPM cuts will align. I don't think that points towards a encoder/indexer error.

which one is which?

\\\

200\150\100\

?

If index is detected properly (at the identical rotor angle regardless of speed)
The Z Axis position should be in strict relation to spindle angle so this does seem to
suggest an Index issue or perhaps a Z axis problem (What are the following error limits?).

Perhaps plotting the z axis position and spindle angle in halscope
while threading at different speeds would shed some light on whats going on...

Your spindle encoder is directly driven by the spindle, just checking.

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.