Fitting an encoder to non Tormach mill (5i25)

Still working on the encoder testing but have been distracted writing Hal components, surprised at how easily and quickly simple components can be created.

This has brought up a couple of questions which I'll ask in the appropriate area.

I've spent a bit of time comparing the encoders in tormach_mill3.bit and 5i25_g540x2.bit to see if the 2nd tormach encoder functions as a proper encoder by looking at the variation in velocity output over a range of RPM, 200 to 3000.

The tormach bitfile and encoders=1 gives the pseudo encoder and encoders=2 again gives the pseudo encoder and a 2nd proper A,B,Index encoder. I've tested the 2nd tormach encoder and a 5i25_g540x2 encoder in both counter-mode 0 and 1.

Both encoders gave very similar outputs over the 200 to 3000 RPM range but both show considerable variation in spindle RPM.

The amount of RPM variation is pretty large, count mode 0 gives ±40% at 200 RPM falling to ±20% at 3000 RPM (percentages rounded), count mode 1 gives ±20% at 200RPM falling to ±2% at 3000 RPM (servo period 1mS and vel-timeout 0.1 seconds).

I'm not sure what I'm actually measuring but I'm surprised at the size of the errors.

A strobe light on the spindle shows a bit of rpm variation but not ±40%, I'd guess at a few %.

All in all a bit disappointing, don't think I'm testing the right thing, RPM variation over time, should be trying to detect instantaneous angular velocity between tach edges.

Or maybe I'm just over thinking it and should just have ago.

Sorry for the long post.

Typically you must low pass filter the velocity readings to get stable RPM, especially with home built, low resolution or badly adjusted encoders. This is because the velocity estimate is done by dividing the number of counts by the time between the counts

if you have substantial quadrature error (and a low resolution encoder so you are only getting 1 or fewer counts per sample period) its easy to get 40% speed variation (this just takes a 20% quadrature error)

Possible solutions are:

1. Higher resolution encoder (the quadrature errors contribution to the velocity estimate will be divided by the number of counts per sample)

2. Minimize quadrature error (adjust sensors for 50% duty cycle and 90 degree phase difference between A and B )

3. Low pass filter the velocity value

OK, more edges the better, but is there a cutoff?

For instance at 1000 RPM a revolution takes 60 mS, in counter-mode 0 both edges of both phases are counted so with a 1mS servo period is there anything to be gained by having more than 60 edges, 15 tach square waves per revolution?

With the tormach pulse per rev encoder when the spindle stops the velocity output is held at its last value for at least a second before going to zero, also it has the most stable velocity output by far, about ±4% at 200RPM falling to about ±0.5% at 3000 RPM. This suggest some filtering or smoothing in the mesa hardware.

My initial thoughts were that filtering defeats the purpose, throwing away information. Unfiltered for motion and filter for the GUI makes sense.

Thanks for your replies.

Did some testing with lowpass filter for display RPM and it works well. With low gain values the output RPM has minimal fluctuation and displays intended RPM changes acceptable lag.

I'm redesigning my DIY optical pickup and tach disc with as many edges I can get.