Lead screws for X and Y: non-integer steps per mm

I'm considering designing a printer with lead screws for the x and y axes. The thing is, the most reasonable screws I found have a lead that results in a non-integer number (in fact, infinitely repeating due to division by 3) of steps per mm. I know that a problem of using non-metric screws on the Z axis causes banding in prints due to the rounding caused by the unit conversion. Would the same thing happen with a metric screw if the number of steps per mm is a non-terminating non-integer? Pardon if the question is obvious, I'm fairly new at this.

The Ormerod printer uses X and Y axes with non-integer steps per mm, and this doesn't seem to cause any problems. The firmware for the Duet electronics used by the Ormerod uses floating point arithmetic for calculating the number of steps. I don't know whether it would be a problem for other firmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

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).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

So I'm guessing it's only a big problem for the z axis where a small error in layer height will wreak havoc on your infill?

Thanks for the info.

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).

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.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
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.

Quote
dc42
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.

Edited 1 time(s). Last edit at 10/14/2014 09:52AM by Traumflug.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY