On 5 July 2012 05:18, Jon Elson <el...@pico-systems.com> wrote: >> Rollover is a non-issue within the lifespan of most machines
> Not necessarily. Assume 3000 RPM and a 1000 cycle/rev encoder. Typical > 24-bit > encoder counters will roll over on a bit over a minute (16 mil/12 mil). > That gets overflowed to 32 bits, so it would take 358 minutes to overflow > the 32-bit count. I think all the encoder counters on LinuxCNC currently > use a 32-bit count internally. Having checked, it seems you are correct. The software stepgen uses 64-bit accumulators, and the Mesa Resolver module uses a 64-bit accumulator too. For some reason I thought all the other encoder-like functions were using 64 bit internal representation. I can't help feeling that they ought to. The software stepgen holds position data in a floating-point (double) representation which will lose precision rather than wrap as the counts increase as long as the 32-bit counter wrap is handled carefully. I think I worked out that it would take an awfully long time for the encoder position to become significantly innaccurate. (assuming that we want a position accuracy of 0.0001" and a float has 15 places of decimal precision, then the notional axis can travel 10^11 notional inches before not being able to represent 0.0001". At a travel rate of 1000 in/min that is 190 years. My initial impression is that the software encoder does not handle the wrap as well as it might. It probably ought to add delta_counts * scale to the position, not recalculate the position from total counts. The magic of twos-complement means that calculating deltas on signed integers handles the wrap automatically. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
