Re: [CAD_CAM_EDM_DRO] Caliper to PC interface, Part II: Data Format Deciphered !
Posted by
krlux
on 2001-10-19 14:39:18 UTC
Hi people.
I know the problem of deciphering the data format on the imported caliper
was keeping some of you awake at night, so I'll share the partial solution.
a) In the first part of the datastream, the caliper outputs a 20 bit
bitstream "equal" to the current reading on the LCD. (See examples below.)
b) The data stream that I speak of is a 20 bit two's complement number,
starting at bit 2 and going to bit 21. (I'm calling the first bit bit
one... software types sometimes call that bit bit zero.) I've written
"1234567890123456789" over these bits in the example below.
c) Reading the caliper this way, it has a resolution of 1280 divisions per
inch. Why 1280 ? I suspect the caliper operates on a vernier principle
and one part of the vernier is 10 parts per inch and the other part is 128.
(128 = 2^7 = easy for microcontrollers to do the math.) Actually, I suspect
this caliper has a higher resolution that 1280 divisions per inch, but I
have not tried to decipher more than 20 bits. It would make sense both from
a computational point of view and from a resolution point of view to have
2560 divisions per inch and I suspect it does.
Here are a couple more thoughts:
1) The caliper outputs this data all the time, whether the LCD is running or
not. As long as the battery is in the caliper, it outputs the data and
doesn't loose its position. When used in a DRO, "home" will always be
"home".
2) I suspect the absolute position of the caliper is in the second half of
the datastream, probably the same sort of format. I don't have time to
decipher that right now.
3) 20 bits = 2^20/1280 = 819 inches of motion. Why does this matter ? I am
in need of a number of DRO scales. The "scale" on these calipers is a
simple etched printed circuit board. I am going to have a local PC board
supplier etch some 40"+ scales so that I can have a DRO for my lathe and
mill and...
4) About the only hickup in terms of using a PC for a 3 axis DRO is that the
parallel port only has 5 bits of input and 3 calipers need 6 bits... I'll
need some time to solve that problem.
Thanks to everyone that provided input to the problem.
Someguy.
Here are some bitstream examples to illustrate the point:
LCD Reading: 0.0085":
12345678901234567890 I
0000000000000000010110001010000000001110010010011 49d = 11 decimal
1000000000000000010110000010000000001110010010100 49d = 11 decimal
0000000000000000010110001010000000001110010010011 49d = 11 decimal
00000000000000001011 = 11 decimal. 11/1280 = 0.008594"
0.301:
12345678901234567890
1000000000001100000100000010000000000010100100100 49d = 386 decimal
0000000000001100000011101010000000000010100100111 49d = 385 decimal
0000000000001100000011011010000000000010100101001 49d = 385 decimal
1000000000001100000011100010000000000010100101000 49d = 385 decimal
0.602:
1234567890123456789
0000000000011000000101011001111111110110100011001 49d = 770
1000000000011000000101100001111111110110100011000 49d = 770
1.000:
1234567890123456789 I
0000000000101000000010011001111111100110100110001 = 1281
1000000000101000000010100001111111100110100110000 49d = 1281 decimal
2.000:
1234567890123456789
0000000001010000000000111001111110111110100111101 49d = 2560
1000000001010000000000100001111110111110101000000 49d = 2560
4.000:
1234567890123456789
1000000010100000000000100001111101101110101000000 49d = 5120
6.000:
1234567890123456789
1000000011110000000000000001111100011110101000100 49d = 7680
0000000011110000000000011001111100011110101000001 49d = 7680
I know the problem of deciphering the data format on the imported caliper
was keeping some of you awake at night, so I'll share the partial solution.
a) In the first part of the datastream, the caliper outputs a 20 bit
bitstream "equal" to the current reading on the LCD. (See examples below.)
b) The data stream that I speak of is a 20 bit two's complement number,
starting at bit 2 and going to bit 21. (I'm calling the first bit bit
one... software types sometimes call that bit bit zero.) I've written
"1234567890123456789" over these bits in the example below.
c) Reading the caliper this way, it has a resolution of 1280 divisions per
inch. Why 1280 ? I suspect the caliper operates on a vernier principle
and one part of the vernier is 10 parts per inch and the other part is 128.
(128 = 2^7 = easy for microcontrollers to do the math.) Actually, I suspect
this caliper has a higher resolution that 1280 divisions per inch, but I
have not tried to decipher more than 20 bits. It would make sense both from
a computational point of view and from a resolution point of view to have
2560 divisions per inch and I suspect it does.
Here are a couple more thoughts:
1) The caliper outputs this data all the time, whether the LCD is running or
not. As long as the battery is in the caliper, it outputs the data and
doesn't loose its position. When used in a DRO, "home" will always be
"home".
2) I suspect the absolute position of the caliper is in the second half of
the datastream, probably the same sort of format. I don't have time to
decipher that right now.
3) 20 bits = 2^20/1280 = 819 inches of motion. Why does this matter ? I am
in need of a number of DRO scales. The "scale" on these calipers is a
simple etched printed circuit board. I am going to have a local PC board
supplier etch some 40"+ scales so that I can have a DRO for my lathe and
mill and...
4) About the only hickup in terms of using a PC for a 3 axis DRO is that the
parallel port only has 5 bits of input and 3 calipers need 6 bits... I'll
need some time to solve that problem.
Thanks to everyone that provided input to the problem.
Someguy.
Here are some bitstream examples to illustrate the point:
LCD Reading: 0.0085":
12345678901234567890 I
0000000000000000010110001010000000001110010010011 49d = 11 decimal
1000000000000000010110000010000000001110010010100 49d = 11 decimal
0000000000000000010110001010000000001110010010011 49d = 11 decimal
00000000000000001011 = 11 decimal. 11/1280 = 0.008594"
0.301:
12345678901234567890
1000000000001100000100000010000000000010100100100 49d = 386 decimal
0000000000001100000011101010000000000010100100111 49d = 385 decimal
0000000000001100000011011010000000000010100101001 49d = 385 decimal
1000000000001100000011100010000000000010100101000 49d = 385 decimal
0.602:
1234567890123456789
0000000000011000000101011001111111110110100011001 49d = 770
1000000000011000000101100001111111110110100011000 49d = 770
1.000:
1234567890123456789 I
0000000000101000000010011001111111100110100110001 = 1281
1000000000101000000010100001111111100110100110000 49d = 1281 decimal
2.000:
1234567890123456789
0000000001010000000000111001111110111110100111101 49d = 2560
1000000001010000000000100001111110111110101000000 49d = 2560
4.000:
1234567890123456789
1000000010100000000000100001111101101110101000000 49d = 5120
6.000:
1234567890123456789
1000000011110000000000000001111100011110101000100 49d = 7680
0000000011110000000000011001111100011110101000001 49d = 7680
Discussion Thread
krlux
2001-10-19 14:39:18 UTC
Re: [CAD_CAM_EDM_DRO] Caliper to PC interface, Part II: Data Format Deciphered !