Meaning that if, for example, you start with the count near zero and run it with the drill at ca. 250RPM for one minute, then the count on the PID screen ends up in the vicinity of 2,000,000?
If so, then the question should go to the software staff at Centroid. To the best of my knowledge, the status window actual-RPM display (with P78 = 1) has no multpliers except for varying spindle range (and that would only apply with bit 4 of P36 set).
The 3.5V and 0.5V thresholds are for the encoder connection detector circuit. The actual voltage thresholds may also vary based on the generation of your control card. If you are not getting "Bad Encoder Connection" messages, this is not a big problem. Other than the message, the levels only have to meet normal RS422 levels.
The E6B2-CWZ1X is only rated to 100khz. This means the top speed will only be about 3000RPM. Not sure if you noticed this or if it will be an issue for your application, just pointing it out.
Good catch on the frequency limit. I ordered a 100 PPR encoder a few days ago, it will keep me below the limit.
Tech support had me re-apply the latest 2.72 update, thinking that there may be a corrupted file, but it still reads high even at low rpm.
I'm not seeing the index asterisk pulse on the PID screen so I'm still leaning to there being a signal level issue. The encoder counts without errors even with the Z index removed. I'm stumped.
We put a buffer one each of the signals to bring them all above 3.5V. The Z index signal was around 3V and we felt it was below the typical 3.5V cmos threshold. With the buffer all signals are now measuring 4V AND the Z index asterisk is showing on the PID screen. It doesn't appear the index is used because the displayed speed it still high with or without it connected. At least now I can confirm all A, B, & Z signals are being seen.
I believe we upgraded the CPU to 1000mHz about 4 years ago when we added memory and upgraded to 2.72. Is it possible the that CPU speed change resulted in a change? Because RPM is a function of time would the CPU change affect the kernel timer or ticks?
I believe that the software is looking at the DSP clock on the CPU7/CPU10 board for its time reference, and so is not dependent on the speed of the PC processor. Not that it would be anyway; there are plenty of reliable ways to get reasonably accurate times on the PC side which are independent of CPU speed.
The DSP clock on the CPU7/CPU10 should update at 4kHz (the chip's interrupt rate). That counter is made visible to the PC software through a dual-port RAM (memory-mapped I/O). If it were not updating at 4kHz, you would have serious axis-control problems, because it is that 4kHz interrupt which runs the PID position-control loop.
Also, if the clock were counting too fast, then the reported spindle speed would be low (fewer encoder counts seen per each interrupt). In order for the DSP clock count to cause the spindle speed to read high, it would have to count too slow.
Did you do anything to change the clock crystal associated with the ADSP-2101 chip on your Centroid CPU board?
The latest from Centroid tech support is that the MSI MS-6368 motherboard I have in the PC does not support greater than v2.36 even though we upgraded to v2.61 in 2008 and v2.72 about 4 years ago. Not sure if it's a motherboard issue or motion control card issue. Support was kinda vague on the particulars and they wanted me to send the PC in. I can't really handle the downtime. Aside from the rpm display after putting on this spindle encoder we haven't had any issues. Zero! Now I need to pop the PC panel and see if it's really running the ISA motion controller or not.
I booted it up on v2.61 yesterday and it exhibited the same issue. Now I really want to try v2.36.
Centroid tech support was able to duplicate the issue. They said the spindle display shouldn't affect my ability to rigid tap and sent a demo code to try it. They recommended setting parameter 78 to display programmed speed instead of encoder speed. Still trying to learn if upgrading the motherboard would correct the issue.