Jon Elson wrote: >Jeff Epler wrote: > > >>In emc2 there are practical limits on the precision of position values due to >>the use of "float" as the fundamental type for "analog" values such as >>encoder positions. For instance, the values 1.0 and 1.0 + 0.5**23 >>(approximately 1.0000001) are both exactly representable, but no values >>in between those two can be represented. Similarly, 2.0 and >>2.0 + 0.5**22 (approximately 2.0000002) are both exactly representable, >>but no values in between those two can be represented. >> >> http://en.wikipedia.org/wiki/Floating_Point#Implementation_in_actual_computers:_IEEE_floating-point >> >> >> >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, 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.
> 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. >But, there is another, much more serious limit! Some of the >EMC2 drivers expand raw encoder counts to a 32 bit integer, >first! Looking at the hal_ppmc.c driver, it takes the 24-bit >hardware counter result, and adds a 4th byte, and handles sign >extension and overflow to form a 32-bit count, and then unions >that onto a long integer. (Hmmm, I thought long was 64-bit, but >looking it up, I see it is only 32.) > > I think the mesa has (or could certainly be changed to have) a 32-bit position counter. As long as the position counter is large enough to hold one revolution of the motor (not the screw), it's OK. That requirement is only there for index to work properly - EMC2 could keep track of the encoder counts even if you had 20 million counts/rev, but index wouldn't work correctly. [snipped code snippet] >Does the canonical encoder interface so things differently? > > The canonical encoder has a 32-bit count value, and a float position value. How it calculates those values is up to the driver writer. There isn't much leeway though, because the scale parameter is also a 32-bit float. It is possible to change drivers to use doubles internally (the scale would have good precision because it's just a tiny number, not a tiny number added to a large number), with the "down-rezzing" done when the position output is converted to float. >If Aram goes ahead with this project, it will be necessary to >expand the raw encoder count to a longer word. > We've discussed various methods of handling larger data types, which this would require. The good news is that once we have that, we can use doubles anywhere. > Do any of the >other encoder interfaces use the same 32-bit integer value? > > Yes, since a hal_s32 is a 32-bit int ;) - Steve ------------------------------------------------------------------------- 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
