Resolution integer math assistance?

[kevlar129bp]

Hello guys,

Chris again...:confused:
I've shelved my encoder digitizing arm project at the moment, in favor of another encoder project that is viable now...and it only involves 1 encoder.

Here's what I've got:

This project is intended to measure the angle of a die in an air-over-hydraulic tubing bender.
Maximum angle measurement of bend will be 190 degrees.

Encoder specs:
500 CPR
2000 in quad

Belt drive reduction:
Encoder: 10 Tooth 3mm HTD
Die: 44 Tooth 3mm HTD
Ratio: 4.4:1

Therefore:
4.4 * 2000 = 8800 Counts per 360 Degrees
Count resolution = 360 / 8800 = .040909

Electronics:
PIC16F688
20Mhz
16 x 2 LCD

The question:
I'm WAY foggy on the math to harvest the angle from the encoder counts...
Easy with floating point... "current count * .040909 = angle".
I would like to have the resolution to be "###.##' on the lcd display.
For ex: 1400 counts would display "057.27".
I've read a ton of info on the forum in regards to floating point math, I just can't get my noodle around it :o.
Could one of you fine folks point me in the right direction?
I would post my code here, but all it is, is redundant encoder code so far...missing the holy grail math :).
The couple of pics are for reference.

Thanks to all of you!
Chris

[Darrel Taylor]

Ang = current_count * 40909
Ang = DIV32 10000

LCDOUT DEC3 Ang/100,".",DEC2 Ang//100

[kevlar129bp]

Thank you so much DT! :)

I'm working on the rest of the code as we speak.
I think I get the following...

Ang = AngCount * 40909
Ang = DIV32 10000

DIV32 effectively "slides" the decimal point so the final number is 5 places max?
I think I got tripped up thinking ALL math had to fit in 16 bits.

Ang = AngCount * 40909 <<<< potentially way bigger than word sized

My bad! You are so gracious for helping! Thank you a bunch.

Chris

[Darrel Taylor]

No prob Chris,

For a lot of things, you really don't need Floating Point math.
When multiplying and dividing, the decimal point doesn't matter (until you get the final answer).

For X * 0.040909 ...
Just drop any leading 0's and keep anything that will fit with-in 16-bits (<=65535). Anything more, and you have to drop digits to the right.

At the end, you'll remember that the decimal point shifted 6 places to get that.
Which leaves 40909. Multiply that times the number you are converting.

Since the number had 6 decimals, and you want 2 decimals left in the result ... then there are 4 decimals unaccounted for.

Ang = DIV32 10000

Dividing by 10,000 shifts it those 4 decimal places. 1 decimal for each 0.

And yes, it's WAAYYY bigger than 16-bits.
But the multiplication result is temporarily stored in PBP's system variables as a 32-bit number before using DIV32. So a larger than 16-bit variable is not required.

hth,