When I had the encoder connected to my lathe Oak board, I ran the spindle through the complete speed range in both gear ranges, 450-6000 and 0-400rpm. There were no differential or quadrature errors during this process.I do have a question regarding your test on the lathe. At what rpm did you test it ? Also, is the reason you chose 64 bit "06B part designation" to achieve 24,000 rpm ? Is this a worry it could be too coarse, or is this more than adequate for the spindle and likely rigid tapping ?
I chose the relatively low 32-bit "06B" interpolation setting for a couple of reasons. My max spindle speed is 6000 RPM. Centroid recommends a minimum 1024 line encoder (4096 cps) for spindle control. You don't really need much more than that since tapping is usually done at fairly low spindle speeds (400-800)rpm so synchronization with the Z drive does not need a lot of pulses per rev.
One other thing also needs to be considered. The equipment receiving the encoder information will have a maximum data rate that it can handle. Based on previous posts from Centroid this is 1MHz (at least for the Acorn - I'm assuming the OAK/ALLIN1DC will this or better).
So, based on my design speed and a requirement of 1024 lines per rev, I looked for the widest pulse width that would meet these specs (pulse width = 1/frequency. So, 1MHz frequency = 1us pulse width).eng199 wrote:The ACORN can take an extremely high encoder frequency. However, there may be filtering added in the future to reduce the frequency to 1 - 5MHz. To maintain future compatibility, it would be best to consider the maximum frequency 1MHz.
Based on RLS' published max speed tables (https://www.rls.si/eng/fileuploader/dow ... les_01.pdf) for the MR050 axial magnetic ring, "06B" gives 1152 lines per rev (greater than 1024 Centroid minimum), and the "1/C" edge separation gives me a minimum 1us pulse width and a max rated speed of 6073 RPM, both meeting my design requirements.
I probably could have gone for a little higher resolution and narrower pulse width but there would have been no performance benefit, and the risk was higher frequencies are more susceptible to noise and computational issues. Keeping things as simple as possible improves reliability.