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.
File Attachment:File Name: little_lathe.hal
File Size:4 KB
File Attachment:File Name: pyvcp_options.hal
File Size:1 KB
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.
Yes, StepConf .hal doesn't include that line so it defaults to 1.0
is 100 for encoder.0.position-interpolated the large value you tried?
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.
If the spindle is sat on an edge, and vibrating, then the system will see lots of spurious pulses and the position will count monotonically up.
With full quadrature ( A and B ) this doesn't happen, the on-pulse counts up, then the off-pulse counts down.
If there is any chance that you would want to do rigid tapping on the lathe then you absolutely need all three encoder channels.
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.
I ran a lathe for years that couldn't track te encoder above 1200 rpm. It wasn't a problem as the Z axis was nowhere near fast enough to thread at those rpm. Threading re-synchs to the index on every pass, so losing counts at high speed isn't a disaster.
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.
There are digital potentiometer replacements ( uk.rs-online.com/web/p/digital-potentiometers/7239930/ as an example) or you can generally use something like photos.app.goo.gl/DCKF7nEkTF7RCtBo6 (or a ready-to go: store.mesanet.com/index.php?route=produc...oduct&product_id=205 )