Fitting an encoder to non Tormach mill (5i25)

26 Sep 2018 02:59 #117984 by rafferty
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.
28 Sep 2018 11:12 #118098 by rafferty
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.
28 Sep 2018 11:29 - 28 Sep 2018 11:58 #118099 by PCW
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
Last edit: 28 Sep 2018 11:58 by PCW. Reason: fix paren --> smiley
28 Sep 2018 12:01 #118100 by andypugh

PCW wrote: 3. Low pass filter the velocity value

But probably only betwixt the velocity pin and the GUI. It is likely to be better to send the motion.spindle-speed-in pin with a raw value.
28 Sep 2018 21:16 #118149 by rafferty
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.
28 Sep 2018 21:24 #118151 by andypugh
Yes, if you have a few hundred edges per servo cycle (1mS) then the noise will be less than 1%.
At the other end of the scale a single-slot encoder will be super-consistent because it is the same physical slot every time.

Just filter the displayed value, let LinuxCNC handle the real value and move on :-)
04 Oct 2018 15:32 #118443 by rafferty
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.
Moderators: cncbasher
Time to create page: 0.087 seconds
Powered by Kunena Forum