On Thu, Jul 30, 2015, at 10:33 AM, andy pugh wrote: > On 30 July 2015 at 15:23, Karlsson & Wang > <nicklas.karls...@karlssonwang.se> wrote: > > I guess you have start calculation from the encoder counters each time and > > then there will be no problem with add up over time. > > There is a danger of encoder counters rolling over the signed-32 HAL > pin value. (though the counter are internally promoted to 64 bits in > all the LinuxCNC counters). > > Unfortunately the encoder_ratio is not applicable to Mesa / Pico / > General Mechatronics / Pluto hardware counters. > > My hobber uses the floating point position values. There is a danger > of loss of precision after many revolutions with this approach, but no > risk of rollover-based problems. >
To be honest, I think the risk is a lot less now than it was back when that component was created. Back in the day, all HAL signals were limited to 32 bits. HAL floating point values were C "floats" which only have 24 bits of resolution. So you could see 1 degree of error after about 44,000 revolutions of the hob. I'm pretty sure that HAL floating point values are now C "doubles", (thanks mostly to Jeff Epler if I recall correctly) which have 54 or 56 bit resolution. So this issue is far less likely to matter. It would now take 50 billion revolutions of the hob before the resolution caused a one degree error. -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
