Spindle Encoder: Float Precision Issues

Hello,

I have a spindle encoder set up (via EL5151) to output the position/angle as revolutions (float value), which get fed into spindle.0.revs.
I am also using a ddt component to calculate the speed and feed it to spindle.0.speed-in.
This seems to work well enough (the speed needs some filtering for low speeds though, as the time step of the ddt is rather small).

There is one aspect of this though that I don't quite understand, and where I am surprised that I can't seem to find much information about (and people who this causes issues for): float precision.
The raw encoder count gets converted to float revolutions by dividing by a float factor (either in the EL5151 or in the lcec component, I am not sure). If these values are also internally handled as float (which I understand is the case), this should cause issues with the limited float precision, when the spindle has accumulated lots of revolutions:

• The absolute resolution (i.e. minimum step size) of the position becomes large. This makes the output of the speed ddt increasingly "jumpy", needing more low pass filtering to display steady numbers. This also makes spindle synchronized motion (e.g. threading) less accurate.
• The small relative position error caused by the limited precision of the encoder factor becomes a large absolute position error. This makes spindle angle synchronized motion (especially those depending on the absolute angle) less accurate.

How are these issues typically dealt with in LinuxCNC? I can think of ways to avoid them using the raw encoder count and integer arithmetic, but I don't know how to properly do it with the mostly float-based components available in the HAL.

Best Ragards
Daniel