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) 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.
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.)
Hopefully, this is the relevant code :
static void read_encoders(slot_data_t *slot)
{
union pos_tag {
signed long l;
struct byte_tag {
signed char b0;
signed char b1;
signed char b2;
signed char b3;
} byte;
} pos, oldpos;
for (i = 0; i < 4; i++) {
oldpos.l = slot->encoder[i].oldreading;
pos.byte.b0 = (signed char)slot->rd_buf[byteindex++];
pos.byte.b1 = (signed char)slot->rd_buf[byteindex++];
pos.byte.b2 = (signed char)slot->rd_buf[byteindex++];
pos.byte.b3 = oldpos.byte.b3;
/* check for - to + transition */
if ((oldpos.byte.b2 & 0xc0) == 0xc0 && (pos.byte.b2 == 0))
pos.byte.b3++;
else
if ((oldpos.byte.b2 == 0) && (pos.byte.b2 & 0xc0)
== 0xc0)
pos.byte.b3--;
Does the canonical encoder interface so things differently?
If Aram goes ahead with this project, it will be necessary to
expand the raw encoder count to a longer word. Do any of the
other encoder interfaces use the same 32-bit integer value?
Jon
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
