Quote

**dc42**

There still remains the question of the resolution to which the steps/mm is represented in the firmware.

There still remains the question of the resolution to which the steps/mm is represented in the firmware.

Yes, in principle. Not a real world problem, though, because it's far more precise than any mechanics. Teacup uses an integer representing steps per meter, so the maximum additional error introduced is one step per meter of axis movement. All other firmwares I'm aware of use floats, which is usually even more precise, but can also be less precise than 1 step per meter on high resolution stepper drivers.

Quotedc42

I was under the impression that some firmwares use fixed point arithmetic, because the 8-bit Arduinos are rather slow at doing FP calculations.

Perhaps you mean the number of steps for each move. These are indeed usually expressed as integer for better performance. Entirely fine, because a stepper motor can only do a step or not do a step, no fractions possible. It's calculated like

(integer)steps_to_move = round((float)distance * (float)steps/mm)

Before somebody asks: all these errors don't add up. It's an absolute error, it doesn't matter how many movements a print does.

For comparison, error introduced by a 1 °C change of part temperature of a part of 100 mm length is about 10 micrometers, ten times higher than errors introduced by mathematical inaccuracies. If you'd be that keen on precision, you'd have to get room climatisation, first.]]>

Quote

**Traumflug**

Any electronics and firmware plays fine with uneven steps/mm sets, of course. For ages, long before Ormerod was designed. The biggest error intoduced is the distance one microstep moves, or 1 / (steps/mm).

Any electronics and firmware plays fine with uneven steps/mm sets, of course. For ages, long before Ormerod was designed. The biggest error intoduced is the distance one microstep moves, or 1 / (steps/mm).

There still remains the question of the resolution to which the steps/mm is represented in the firmware. If all firmware uses floating point calculations for the axis movement, then you will typically get 24-bit resolution in the calculations. I was under the impression that some firmwares use fixed point arithmetic, because the 8-bit Arduinos are rather slow at doing FP calculations. But Marlin at least uses floating point.]]>

Thanks for the info.]]>