Jon Elson wrote: > Stephen Wille Padnos wrote: >> Jon Elson wrote: >> >>> A very good point! It seems there would be a 25.4 X benefit >>> then by using mm as the user unit instead of inches, in the case >>> of these very high resolution encoders. (I think you mean + 0.5 >>> * 10 ^ -23 in the above)
Nope - the units don't matter at all. This is floating point, not fixed point. Whatever the value is, the resolution is approximately one part in 2^24. If we were able to use doubles, the resolution would be one part in 2^56. >>> >> Nope, it's 0.5 ^ 23. 0.5 is the first digit past the binary point, and >> 0.5^23 is the last bit past the binary point. > It seems to me that : > the value 1.0 + 0.5**23 (approximately 1.0000001) > would be 5, followed by 22 zeroes, followed by 1.0, assuming > that you mean "**23" as x 10 to the 23rd power. > This is not a number slightly larger than 1.0, unless I'm > totally misunderstanding what you are trying to say above. >> We're talking about bits, not decimal digits. The resolution of a float is about 24 bits, or about one part in 16 million. Since it is floating point, the resolution is base on the actual value, not the range. For example, assume you have a 20 foot long machine (240" of travel). The worst case resolution is if zero is at one end and you are at the other. In that case, the position value is 240", and the resolution is 240" / 2^24 = 0.0000143". If you put the zero in the center, then the resolution at the ends is better by a factor of two. In either case, when you are close to zero the resolution is quite a bit better - for example, if you are 12" from zero, the resolution is 0.000000715". We are talking about the inherent resolution of floating point numbers and HAL signals here - not the encoder resolution. In any case, only a truly exotic machine would need to even think about these inherent limits. Steel expands at 10.8 ppm per degree C. The resolution of a float is 0.063 ppm. So a temperature change of 0.006 degrees would cause more error than you get from the resolution limits of a float. >>> This may really be moot in Aram's >>> project as the one million count/rev encoder would provide 5 >>> million counts/inch with a 5 TPI screw, and that is only about >>> 22 bits of resolution, assuming only a couple inches of travel. >>> Even if you tried to do this with a very large machine, say 100" >>> of travel, that's only 100 X 5 X 1 million = 500 million, or >>> about 29 bits of resolution. >>> >>> >> That's just a few bits past the mantissa of a 32-bit float, which is 24 >> bits. >> > Umm, yeah, I had been thinking this was all carried as DOUBLE > floats! Definitely could be a problem with a high res encoder > and a longer machine travel. Not really. The encoder counting uses 32 bit integers to store counts. If you build a machine with 10 million counts per inch, it could be 428 inches (35 feet) long before the encoder counter would overflow. Once the counts are converted to floating point positions, you would be limited to one part in 16 million (24 bits), but that is still 1/100th of the error that would be caused by a single degree of temperature change. Measuring microinches on a machine that is more than foot or so long is a job for NIST and others with temperature controlled rooms and laser interferometers. EMC2's encoder counters and internal data paths are plenty capable of handling any machining application and many exotic NIST type applications as well. Regards, John Kasunich ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
