STEPS_PER_MM_{X|Y|Z|E} should be more precise

[Traumflug]

Currently we use STEPS_PER_MM values to calculate the required number of steps from a given position. However, for half-stepping, belt-driven machines this is not precise enough. The correct value would be about 8.12 STEPS_PER_MM, bringing in an dimension error of about 15% when using the next integer (8).

My idea goes towards using STEPS_PER_M, so precision is increased by a factor of 1000. Didn't have a chance to view this in the light of numerical accuracy/overflow, however.

[triffid]

must check for numerical accuracy- 64 bit math is almost as bad as floating point in terms of slowness and support library size, otherwise go for it. Perhaps we can get the preprocessor to work out an appropriate fixed-point scaling based on fractional steps_per_mm and build volume?

[Traumflug]

Here we go: Our space is 2^31. Our highest demanding stepper motors (200 steps/turn) on the smallest spindle (M6) have 1 mm pitch, the best microstepper has 1/16th steps. This makes 2^31 / 200 / 1 / 16 = 671088.64 mm currently. Critical is the multiplication step, done before the division in decfloat_to_int() in gcode.c.

Introducing a divisor of 1000 when calling decfloat_to_int() reduces this to about 671 mm which is just in the acceptable range. Storing the position is still done in full steps, same values as before.

In dda_create() there's a similar limit of 715 mm mentioned, so we don't really loose much. Folks with bigger sized machines can gain a bit by positioning the home point of the machine near the middle of the table.

Sounds good?

[jakepoz]

Oops, sorry, didn't mean to close the issue!

[Traumflug]

Added an implementation for the above: http://github.com/triffid/FiveD_on_Arduino/commit/91eb11bd1e98fb3cb6a9a811ccd226c3d20c2b64

Please test, as I haven't hardware to measure this kind of stuff.

[Traumflug]

As nobody complains, this apparently works. Issue done :-)