On 02/03/2020 06:46 PM, andy pugh wrote:
On Fri, 31 Jan 2020 at 17:38, Jon Elson <[email protected]> wrote:
Hmmm, some interesting things to note. His input scale is
85333.33 counts/inch.
85333 * 50331 looks like it is very close to a 32-bit
rollover (4294895223).
The PPMC devices use a 24-bit hardware counter, and then
rollover and extension to
a 32-bit integer is handled in the ppmc driver.
Is he using a 64-bit kernel? The size of integers might have changed.
Well, I don't know, I will have to ask! But, I was already
suspecting that.
Anyway, I would point the finger of suspicion here:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/hal_ppmc.c#L1080
It uses a Union which contains 4 bytes and a "signed long" but "long"
is only "at least 32 bits". Some web searching seems to suggest that
"long" is 4 bytes in a 32 bit OS and 8 bytes in a 64-bit OS.
If your customer is using a 64-bit OS then he has found a bug, and one
we may need to squash in many places.
YES, that sure looks like the sort of thing that would cause
this. I never tested hal_ppmc.c on 64-bit
platform, because at the time, it was pretty firm that we
would not be moving to 64-bits for quite
some time. All of this encoder sign extension stuff was
worked out well over a decade ago. I hacked in
timestamp-velocity estimation somewhat less than a decade
ago, that was the last changes to anything
that handled the actual axis components.
Thanks for spotting the issue - probably some careful
placement of uint32_t would put this code
right.
Jon
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
