Encoder Scale Problem - Reporting Wrong RPM

I'm running 1024ppr encoder, with an overdrive pulley ratio of about 1:1.8. Taking some measurements I've worked out 562.934 PPR. My machine HAL file looks like this.

I'm running channels 'A' and 'Z' (index) so maybe I should be counting index pulses to report RPM to pyVCP?
Now here is the weird part.

When I M3 S1800 I can measure exactly 1800RPM at the spindle (not the motor) so the VFD is right. pyVCP reports about 800RPM.
When I M3 S3600 i can measure exactly 3600RPM and pyVCP reports 600RPM. That's right, actual spindle speed goes up and pyVCP shows a lower RPM. Also, when dropping form the incorrect 800 to the more incorrect 600 it dips to 0 RPM first (quickly) then comes back up. There is no belt slip or other mechanical problem, so it has to be my config.

My whole config is online at drive.google.com/open?id=0B1zl3WgbwjPGT0ZWSGNKMUprS0U
Any help would be appreciated.

1800 RPM is too fast for a software encoder counter to accurately
count an encoder with 562 PPR at your ~ 25 KHz base thread

If you run your spindle at lower speeds you should find that the RPM is correct
(Up to about 1200 RPM by my calculations assuming near perfect encoder signals and negligible jitter)

One fix would be to lower your encoders resolution (some encoders have this option)
or swap the encoder for one with say 100 PPR

Another fix is to add a hardware encoder counter

Thanks. That's disheartening to hear. It's an expensive encoder that came installed on a new motor. It doesn't allow for variable PPR. I'll research my options.

I know almost nothing about this sort of thing, but it looks like I could use a 74hc4020 counter as a frequency divider.
Thanks again for your help.

Edit: Looks like if I were running a Mesa card this would be a non-issue. May be time to upgrade.

andypugh wrote:

The pulley ratio means that you may need to supply a separate index pulse if you want to do any spindle-synchronised motions.
Can you swap to a 1:1 ratio? Mesa (or Pico) hardware would still be able to cope.

My encoder is quadrature, but it looks like I'm stuck with only using index until I can divide my resolution down. Or get another encoder which I prefer not to do.

andypugh wrote:

Can you swap to a 1:1 ratio? Mesa (or Pico) hardware would still be able to cope.

Yeah I could, but I want the higher speed. As is I can do about 7200rpm on my mill but I want to go even faster.

Unfortunately index wont work with the software encoder either (same problem: too narrow a pulse to sample reliably with software)

One solution would be to divide the count and then use a Proximity switch on the spindle for index
Note that you need A/B and index for rigid tapping so a simple divider wont work

andypugh wrote:

I may have been unclear.

For threading and rigid tapping LinuxCNC requires a once-per-SPINDLE-rev pulse to the encoder counter. This is used to start the threading pass so that subsequent passes all line up.

If your index is from an encoder that is geared to the spindle then the index will not align with the work (in a lathe) or the tap (in a rigid-tapping mill). This might not matter to you on your machine, of course.

I understand, and have that working on my lathe right now. The code segment I posted above was adapted from my lathe, and I see I have made an error. My lathe encoder is on the spindle and on my mill where I am having the trouble the encoder is on the motor. I seem to be scaling 'A' but not 'Z'.