lathe encoder

I'm having some trouble understanding the encoder on a lathe project. The spindle readout in Axis drops to approx 10 rpm fairly quick when the spindle stops but takes about 10 seconds to drop to 0.1 and never returns to zero.
encoder.0.velocity-rpm reads 0.1397 at stand-still
encoder.0.position-interpolated bounces around crazy on the 3rd decimal and the only way I've found to stop this is increasing min-speed-estimate to many times the default. That doesn't feel like a proper solution and none of the above seems normal.
I've tried both a CUI capacitive and an Omron (knock-off) optical encoder with identical results. Only A channel and index are hooked-up. No synchronisation has been tested as the lathe is still in the build stage. The wiring is very basic since I don't know electronics, wired straight to parallel port..
Is what's described above typical and if not any clues why ?
A HAL file is attached.
btw the spindle speed is manual control.

is 100 for encoder.0.position-interpolated the large value you tried?

that's 1.6 RPM - pretty low for a lathe spindle.
From the manual:

encoder.<chan>.position-interpolated (float, Out) - Position in scaled units, interpolated between encoder counts. The position-interpolated attempts to interpolate between encoder counts, based on the most recently measured velocity. Only valid when velocity is approximately constant and above min-speed-estimate. Do not use for position control, since its value is incorrect at low speeds, during direction reversals, and during speed changes. However, it allows a low ppr encoder (including a one pulse per revolution encoder) to be used for lathe threading, and may have other uses as well.

encoder.<chan>.min-speed-estimate (float, in) - Determine the minimum true velocity magnitude at which velocity will be estimated as nonzero and postition-interpolated will be interpolated. The units of min-speed-estimate are the same as the units of velocity . Scale factor, in counts per length unit. Setting this parameter too low will cause it to take a long time for velocity to go to 0 after encoder pulses have stopped arriving.

Seems to discuss your exact problem. I don't have real world experience with this setting so can't definitively say this is typical.

is 100 for encoder.0.position-interpolated the large value you tried?

Yes, StepConf .hal doesn't include that line so it defaults to 1.0
The spindle doesn't seem to lose track of accumulated position, it's the velocity that's a bit wonky.
If velocity plays no part in sync for thread cutting I can live with the rpm display being a bit unresponsive. The thing is I don't know enough to know if this is a real problem.

I think the manual explains it well enough - there is only so much you can do with a single pulse per rotation.

Real world testing will tell the story - please revisit this thread when you get an answer so others will know.

Chris

Okay thanks. This project will need the big mill and it's still sub-freezing in that space. In other words this won't be completed any time real soon. I could connect the B channel but don't foresee a real need for the intended use. I don't think of it as a single pulse per rev since the A channel is 100 ppr.

Okay I wasn't aware adding a B channel has possible benefits beyond rigid tapping. It doesn't look hard to hook-up or configure so I'll see how that goes. I do want to stay with LPT for now and the encoder can be reduced to 48 ppr if needed. I'm aiming at 4000 RPM max capability but don't expect to be using that speed often or ever, certainly not for cutting thread.

This machine is going to be a mongrel for occasional use. An excuse to build something again really. The headstock is off a Sieg 7x12 and has a 4" 4-jaw chuck. So far the hi/low gears are still being used. The motor and MC-60 control are treadmill salvage. I've added a reverse switch and also kept the flywheel in hopes that it helps steady the rpm. Afaik the MC-60 can only be controlled by potentiometer.