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

Maybe reset the encoder count on each index pulse? Then it would not count to such high numbers. But this will break the speed output of your ddt (I think). Does the EL5151 not have an encoder velocity output? I just used a similar Beckhoff part recently but can't remember, I don't think I used or needed velocity (speed) feedback in that project.

Yes, resetting the counter/position on the index pulse would mess with the ddt and I am pretty sure also with the spindle synchronized motion.
The EL5151 can provide the period between pulses (or pulse frequency), which can be used to calculate the speed, but getting the correct sign of the speed is a bit annoying.
I just found out about the HAL component generator, which looks like it would make proper signed speed calculation from the raw counter value quite simple, I might try that.

The ddt approach seems to be the one getting recommended most though, so I am still surprised that I couldn't find any mention of issues related to that in combination with the float precision.

I still don't see any way to solve the issues related to the precision of the float position, as that seems to be inherent to the spindle component as it only takes position as float.
As an example:
If a spindle runs at 3000rpm for 8h (which may be somewhat realistic for a long manufacturing day), it gets to 1,440,000 revolutions, which are represented as a float value. At this point, the absolute resolution of the float is reduced to 0.125, or 45° of spindle angle, independent of the (likely much higher) encoder resolution. Isn't that a potential problem?

I am just a hobbyist who will likely never run into that issue, but it would be interesting how this is typically solved for more professional setups with long run times.

Well, I found the reason why this is not an issue: for a long time now, floats have been internally implemented as 64bit double precision, not the 32bit single precision that I assumed.
Not sure how I missed that, sorry.

I don't think the precision is an actual issue because for both spindle synchronized moves
and spindle orient, index is used so the spindle angle is zeroed before the operation.
This means that you would normally not see a significant loss of precision in the small
number of turns needed by these operations.

Can the EL5151 provide integer counts? If so, they could be easily converted/dewrapped to
a LinuxCNC hal float (which is 64 bits)
 

Yes, the EL5151 provides integer counts, which get converted to float by the LinuxCNC EtherCAT driver.
So with the misconception of floats having only 32bit being resolved, everything makes sense now.

Hello Daniel,I have exactly the same setup as you.
Do you mind sharing your Hal and ini file for this specific parts please? It would save me a lot of time

Thank you in advance