Category: Driver Boards
The issue with the sampling speed has to do with velocity calculations,
mainly at lower speeds or lower resolution encoders:
Imagine you have a 1000 count (250 PPR) encoder turning at 30 RPM (= 0.5 RPS so 500 Hz count rate)
If sampled at LinuxCNCs standard 1 KHz rate, you would get 1 count every other
sample, since the most basic velocity calculations would use the difference in counts to determine
the velocity, the velocity calculation would alternate between 0 RPM (count change of 0) and 60 RPM
(count change of 1). At higher speeds the problem gets better but does not go away, at 90 RPM
with the same encoder/sample rate, you would get alternating counts of 1 and 2 so alternating
velocity calculations of 60 and 120 RPM.
You can of course filter the velocity value since the average value will be correct, but this is not desirable
if the velocity is used for feedback as it lowers the control bandwidth.
The normal way this is improved is by velocity estimation, which changes the velocity calculation from
delta_counts/sample_time to delta_counts/time_between_counts. This typically requires that the low level
hardware timestamp count changes to allow the time_between_counts to be determined.
Once you have decent velocity estimation, you can do tricks like position interpolation, allowing
use of very low resolution encoders for constant speed spindle synchronized motion like threading.
