Klipper: QOL request : Allow step_distance in the config file to be specified in steps/mm

[joonadec]

Hello,

Would it be possible to allow step_distance to be specified in steps/mm instead of the current mm/steps?

Currently I need to convert steps to a decimal, by calculating 1/steps, which I feel isn't that intuitive, as well as having to using 6-7 decimal places in the config file.

What about one of these conventions below?

a) Be able to use fractions e.g. step_distance: 1/80
b) A suffix for the value e.g. step_distance: 80E

I know that getting this value is more or less fixed for X, Y, Z axies, but its pretty much busy work if you're trying to calibrate extruder esteps.

Joon

[AxMod3DPrint]

Honestly, imo, it's just an extra step and not that much more effort. I
know it's not overly intuitive, at first, but physically setting the
distance per step over setting how many steps the printer needs to do for
1mm is from my perspective and understanding more accurate and is one less
calculation klipper has to do when a move is commanded, which would slow
everything down. Although letting Kevin and others chip in here as they
could probably give a better rational than I.

On Fri, 25 Jan 2019 at 02:03, joonadec [e-mail] wrote:

Hello,

Would it be possible to allow step_distance to be specified in steps/mm
instead of the current mm/steps?

Currently I need to convert steps to a decimal, by calculating 1/steps,
which I feel isn't that intuitive, as well as having to using 6-7 decimal
places in the config file.

What about one of these conventions below?

a) Be able to use fractions e.g. step_distance: 1/80
b) A suffix for the value e.g. step_distance: 80E

I know that getting this value is more or less fixed for X, Y, Z axies,
but its pretty much busy work if you're trying to calibrate extruder esteps.

Joon

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/KevinOConnor/klipper/issues/1151, or mute the thread
https://github.com/notifications/unsubscribe-auth/AQULnuD0_gK7kS-oZkdJX46rmSyU3PcCks5vGmX8gaJpZM4aSD3P
.

[teikjoon]

Doesn't need to be recalculated each time, having configfile.py convert the value as it reads the config file should be a one-off

Also, a simple if statement -

if (step_distance > 1):
step_distance = 1 / step_distance

should be all that's required, and step distance can then be specified in both mm/steps and steps/mm :)

[jakep82]

Kevin has commented on this previously. The choice to use mm per step is very deliberate.

https://github.com/KevinOConnor/klipper/issues/934#issuecomment-448402070

[jakep82]

Also I think the only reason it's unintuitive to some people is because they're coming from Marlin. The math is exactly the same either way. For a 20 tooth pulley on a 1.8 degree motor with 1/16 microstepping it's just 40/3200 versus 3200/40. No extra work is necessary.

[JohnEdwa]

For most people the only thing that actually matters is the extruder steps as the X/Y/Z are almost always clean whole numbers.
On Marlin, calibrating the extruder is (current_steps * 100) / distance_extruded rounded to two decimals, so (88.33/100) * 103.2 = 91.15656 -> 91.16.
On Klipper it's (100/distance_extruded) * current_steps rounded to... something, I guess? which looks messy: (100 / 103.2) * 0.01132118193 = 0.01097013752

And well, the most obvious reason - because steps/mm is the standard used by pretty much everyone else. But if following the standards or conventions was ever a thing with Klipper the whole 'extended G-code' thing wouldn't exist in the first place.

[teikjoon]

And well, the most obvious reason - because steps/mm is the standard used by pretty much everyone else. But if following the standards or conventions was ever a thing with Klipper the whole 'extended G-code' thing wouldn't exist in the first place.

This is my point exactly, when people (like me) are trying out klipper for the first time, there are already Marlin numbers to copy...and having to get the inverse, 6-7 decimal point value of this seems more work than necessary :)

[KevinOConnor]

The reason Klipper does this is to use consistent units of measurement in the config file (millimeters for distance, amps for current, volts for voltage, seconds for time, ohms for resistance, etc.). This has come up a few times before so I've expanded the FAQ for this (commit 71ef715a).

To be clear, this choice is not related to performance at all. Indeed, it's the opposite. It is my general understanding that steps_per_mm originates from an attempt to micro-optimize code on old 8-bit micro-controllers (dating back to GRBL which is the genesis of much of the reprap style 3d printer firmware today). If one takes a step back, I think they'll agree that specifying this one distance in units of "inverse millimeters" really is very quirky.

One can calibrate an extruder distance using the formula: new_step_distance = actual_distance_extruded * old_step_distance / commanded_extrude_distance and then round to six decimal places (six decimal places is nanometer precision - anything more precise would be "splitting atoms").

And well, the most obvious reason - because steps/mm is the standard used by pretty much everyone else.

This point is well taken. It would certainly be a shame if users didn't adopt Klipper because of something so trivial. That said, Klipper is dramatically different from other firmware - it has to be because the architecture is so different. I can't help but feel that if a user can't get past something so trivial that they'll also not be able to get past many of the other, more fundamental, differences.

FWIW, I do find step_distance to be easier to work with mentally - for example, if I see an extruder step distance of 0.010970 I immediately read it as a distance of 11 microns. I do have a "general sense" of what a micron is (relative to other things like the width of human hair) and what a nanometer is (relative to the nominal diameter of an atom). I have no idea what a 91.16 steps_per mm is - to me it's just a "magic number".

Cheers,
-Kevin

[JohnEdwa]

That said, Klipper is dramatically different from other firmware...

It is, but it doesn't mean it is forced to reinvent the wheel in backwards incompatible ways. The Extended G-code for example is much more human readable and clearly superior to the old G and M commands based on stuff from the 50's, there's no doubt about that. Adding support for those in Marlin for example would make it a better firmware.
But there is also no reason for Klipper to not respond to "G29" with "Right, one BED_MESH_CALIBRATE coming up" or "M851 Z4", "Oh, SET_GCODE_OFFSET Z4, sure".

For example, that's exactly what RepRapFirmware does for some commands like the M851:

M851 in RepRapFirmware 2.02RC5 and later: M851 Znn is implemented for backwards compatibility with other firmwares.

(Speaking of that, I wonder how the RepRap G-code wiki is going to be able to include Klipper. Klipper doesn't support "G29", but "BED_MESH_CALIBRATE" does the exact same thing, so G29 for Klipper is clearly a No, yet kinda... yes?)

---

I do find step_distance to be easier to work with mentally... ...to me it's just a "magic number".

I agree with you on both. Having step distance as a mm/step is more logical and the step values don't mean anything on their own. Still, it wouldn't hurt implementing both "step_distance" and "steps_per_mm" or the "step_distance: 1/80" to be backwards compatible, as pretty much every user of Klipper is going to come from some other Firmware using those values.

In the end I totally understand why you have chosen to do these this way and I completely agree that they are a better implementation. I just don't think addin yet another way to command 3D printers to the already too long list is a good idea.

[joonadec]

Thanks for your responses...I'll close this then.