Fair, the magnitude case is rare and I won't push it. But the behaviour at the 
limit differs. An integer counter wraps at a known point and we already 
reconstruct it: hal_extend_counter() extends limited-width counters to 64 bits 
with the usual modular trick, so the count just keeps going, no discontinuity, 
no lost counts. A float past 53 bits doesn't wrap, it degrades silently, x + 1 
== x and the count eventually sticks, with no boundary to detect and nothing to 
recover. So where it matters, the integer keeps counting correctly and the 
float quietly loses count.

Either way, magnitude isn't the only reason for integer pins. It's also the 
values that aren't counts: registers, status and fault words, masks. Those 
don't round or wrap, the bit pattern just has to survive, which a double can't 
do. sserial already carries them as hal_u32_t pins for exactly that reason.

One honest question: what would bitslice and bitmerge operate on without an 
integer type? Their job is word-to-bits and bits-to-word. On a float the 
conversion back to a bit pattern becomes implicit, and anything past 53 bits 
can't round-trip. I'd genuinely like to know what the intended replacement is, 
are we just dropping them in your model?


On June 7, 2026 10:03:29 PM GMT+08:00, andy pugh <[email protected]> wrote:
>On Sun, 7 Jun 2026 at 13:03, Luca Toniolo <[email protected]> wrote:
>
>> We do not have to hypothesize, because we already hit this. hostmot2
>> computes a 64-bit internal encoder accumulator specifically to stop
>> high-count encoders wrapping:
>
>We have one(?) known case of a high-count encoder on a high speed
>spindle wrapping at 32 bits. I think it took a long time to happen.
>
>In that case even an extra 5 bits would probably have solved the
>problem, making the wrap take a month rather than a day.
>
>There may be cases where 53 bits isn't enough, but they don't seem
>realistic. For example if we take the case of a 32-bit encoder on a
>high-speed spindle running at 100,000 rpm (and it makes no sense
>_at_all_ to have a 32-bit encoder on a spindle) then it would start to
>become inexact in a float after 20 minutes of running. (whereas with
>the full 64 bits this would wrap in a month)
>
>Note that 32 bit encoders are probably the highest current resolution,
>and are intended for angular measurement, not for counting multiple
>revolutions. And they probably can't handle 100k rpm.
>
>-- 
>atp
>"A motorcycle is a bicycle with a pandemonium attachment and is
>designed for the especial use of mechanical geniuses, daredevils and
>lunatics."
>— George Fitch, Atlanta Constitution Newspaper, 1912
>
>
>_______________________________________________
>Emc-developers mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/emc-developers

_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to