Re: [CAD_CAM_EDM_DRO] Re: encoder to tach converter idea (was killer deal...)

skykotech wrote:

>Got it. I understand what you mean now when you were talking about
>the lack of information with encoders vs tachs at slow speed. I
>didn't realize a tach that was like 5V per 1K rpm would even have an
>output at 0.001 rpm...I assumed any voltage generated by the tach
>would get lost in the noise level of the circuitry or cables. So at
>what point does the resolution of an encoder match that of the best
>tach? I have 2500 line encoders (10,000 in quadrature) on my cnc
>mill motors, and I have to think that is pretty dang good. Even at
>0.1 RPM, I would still get 16 counts per second. 0.1 RPM would be
>about 0.02 IPM on my mill.
>
>But if I had 200 line encoders, or even 500 line encoders, then I
>could see where there could be problems.
>
>Thanks for the explanation.
>
>Rick
>

Even at 10K counts/rev, you'd have the same issues - 16Hz is still about
60 ms per encoder count.

Think of it this way:
Assume you're running something that does 1000 velocity updates per
second. For feedback, you read some counter that has the number of
encoder counts that occurred in the last millisecond.
So, 59 times out of 60, there's no count, and it looks like the motor is
stopped.
Then suddenly, the counter shows 1 count. It looks like the motor
instantaneously accelerated to one count per millisecond or 6 RPM!

If you want 1% resolution for 1000 updates per second at 1 RPM (without
averaging - an instantaneous reading), then you would need a 6M line
encoder (1000 updates per second * 100 counts per update / (1/60 RPS =
1RPM) lowest speed). The minimum for detection of movement in every
update cycle in this example is a 60K count encoder.

Things are never simple when moving from the digital world to the real
world.
- Steve

(note - I'm not suggesting that a "digital" CNC system needs mega-high
resolution encoder feedback, this is just an exercise in thinking about
differences between analog systems and digital substitutes)

(note 2: I just thought of an interesting way of averaging encoder
feedback. In each period, read the count. Sum the counts from previous
periods until you either reach (or pass) a predetermined number of
counts (like 100 for 1% accuracy), or until you have summed a certain
number of samples periods. Divide the count by the number of samples,
and you have a rate that should be accurate to your desired percentage.
Advantage is that at high speeds, the averaging period decreases, giving
higher update rates at high velocities. At low speeds, some accuracy is
maintained over longer periods of time. Hmmm.....)