Hello, I am a big fan of Klipper firmware and I am finally expanding my horizons to new ways of 3D-printing. I have read through a lot of discussions as well as the documentation, but no one seems to have the same problem I do. Any help is greatly appreciated!
Information about my printer:
It uses a cartesian coordinate system, but the x-axis motor is used to turn a cylindrical ‘print bed’ around the Y-axis. It is intended to print tube-like parts with increased strength compared to normal cartesian printers.
My problem:
As the height of the part increases, so does the circumference. This means that one rotation of the X-axis corresponds to a longer travel distance along the printed part. In the past, I used Marlin’s M92 command to set the “steps per millimeter” to reflect the current circumference, but I could not find a Klipper analogue.
The question:
Is it at all possible to change the “rotation distance” property with gcode mid-print? If not, is it possible (easy enough) to change something in the code which would allow me to do something similar?
I don’t think that is not found in Klipper, but someone may have added something extra. For extruders there is ‘SET_E_ROTATION_DISTANCE’.
What is missing for extruders is a variable where in a macro one can read back the value that has been set (‘rotation_distance’: self.rotation_distance). If you get help with an addition to the code, be sure to include this as well. This simplifies the macro.
Thank you for your reply! I will see if I can find the “SET_E_ROTATION_DISTANCE” implementation in the source code and (if at all possible) try to do the same for other axes. I would still greatly appreciate any help or guidance from someone who’s more experienced with the inner workings of Klipper than me
@olhev to be clear: Extrusion is not a problem, the rotation of the x-axis is. If I want to print x-mm in the x-direction, the printer needs to know how much to turn the motor based on the height of the part. If I were to work with degrees instead of mm, the problem is kind of solved, but it creates a speed problem. At larger diameters, a rotation would produce a much higher nozzle speed relative to the printed part than at smaller diameters.
I am making my own slicer so extrusion math and units can be what I need them to be.
It is a coreXY setup with 3 Z lead screws. The “rotary module” will essentially be a stepper motor attached to the Z lead screw on the back with the shaft facing forward (red arrow)
CoreXY would be disabled, and both motors would be set up as Y-axis motors. That way I can “disable” the X-axis of the coreXY setup and use the new motor as X.
My bad, there is no gcode for the XY rotation distance but you can still change inner parameters of the printer via macro, just I’m on the phone and I cannot easily find it right now.
Indeed this is not something supported by Klipper out of the box. Besides the PR you referenced, you may find it useful to try the new generic_cartesian kinematics being developed. There I added a support of the SET_STEPPER_KINEMATICS command. While originally I had other usecases for it in mind, you could conceivably use it to scale the stepper movements for a given axis in case you have a plain Cartesian kinematics, e.g. if you have in the config
[stepper x]
kinematics: x
....
then during the print you could issue commands like
which would make stepper move 0.5% more on X axis movements.
Just one thing to keep in mind, regardless of which approach you choose. It is very important where the toolhead is when you change the rotation distance or axis scaling. This is because when you change the scaling, the toolhead won’t move, but all subsequent moves will be scaled relative to the position where the command was issued. So you may need it to be either in the center of the print, or stable on one side of the print, depending on what you want to achieve exactly. Also, I don’t think axis scaling would work well if you are printing in vase mode, as you want to scale the axis with Z, and in vase mode Z changes continuously.
You mean, the current kinematics? It is exported as printer.toolhead.stepper_kinematics as a map from stepper name to an array of x,y,z coefficients, e.g. you can read X axis scaling as printer.toolhead.stepper_kinematics['stepper x'][0] in a macro.
Thanks. This is something I hold dear. I think that every time there is SET_SOMETHING there should be an opportunity to read this back. This avoids creating a variable in a macro. Which may be used by several other macros.
Should the last [0] be included? Haven’t seen anything like this before.
The exported is an array of coordinates, so [0] would be X, [1] would be Y coefficient, and so forth. The code that exports all this stuff is here. And in general, if you check Status reference - Klipper documentation, you can find many instances like this, e.g. printer["neopixel <config_name>"].color_data[1][2].
