Threading Index Varies With Speed

Good catch. I ran the test again, and noticed that HalScope does not update the picture except after every scan - that was probably the problem. I also made all the pictures at 100 ms per division. Here are the revised photos. I also made a zoomed in photo of when the movement starts, so I could read off the delay.I'm not sure if that has any significance.

100 RPM - 30ms from falling index to start of Z movement
 

200 RPM - 17ms from falling index to start of Z movement

Here's another interesting example. I first made a threading scratch pass at 50 RPM. When the second pass started, I cranked the spindle speed quickly up to about 300 RPM (I'm guessing), then back to 50 RPM. The second cut started overlaying the first, then went to the right as the speed increased, then back to the original cut at the end.

So the speed definitely affects the Z position, and my original concern about the lathe bogging down during threading in a deep cut and then that slowdown causing gouging is warranted.

One thing on the plots, adding the Z velocity would make analysis easier.
Both in determining the start of motion and the point where Z motion
becomes synchronized with spindle rotation

Also an actual screenshot is easier to check than a picture because its
accurate and does not have geometric distortion. (making it hard to tell if
lines are straight)

Here are the requested outputs

100RPM
   


200RPM
   

The 100 RPM plot looks as expected, (It would probably be less jagged if the
interpolated encoder position was used) but the 200 RPM plot is definitely broken.
 I don't understand the slow exponential velocity rise. Plotting the commanded velocity
would discriminate between LinuxCNC motion issues and hardware side issues.
Also , plotting the spindle position might help the diagnosis.


I would try doubling the acceleration to see if that helps (Increasing the acceleration
may _require_ using interpolated spindle position as the large Z position staircase
from having only 10 counts/turn will be less filtered.)

Here's the values for Z:
MAX_VELOCITY = 1.8
MAX_ACCELERATION = 2.0
These were set after a lot of experimentation. Higher values stall the stepper motor. I could try increasing the acceleration somewhat, but probably in the 10-20% range. Not sure this would make much difference. Let me know if you think I should try it anyway.

You mentioned that the 200 RPM plot is broken. Are you referring to the change of slope in the velocity before it starts oscillating?

Is it likely that the 10 pulse/revolution pulses are causing the problem? I could redo that part of the lathe. Getting greater acceleration will require a new stepper or servo motor and a lot of work.

I have two choices for the encoder-

1) I have some encoders in my junk drawer. They're both quadrature. One is a US Digital 1000 pulses/rev with a separate index signal, and the other is a more robust looking Accu-coder 2500 pulses/rev. Both are designed for small shafts, so I'd need a belt or gearing to connect them.

2) I could machine a gear to bolt on the spindle pulley. It'd be about 7 1/4" or so in diameter, so how ever many teeth I could fit on it. Maybe about 90 1/8" teeth? Or 180 1/16" teeth? I don't have any feel for how many pulses/revolution is appropriate, so maybe this would not work.

Here's a photo of the two pulse generators. The 1 pulse/rev is magnetic and the other one is proximity. The teeth are for locking the spindle.