I am completely new to Klipper and loving the granular control of my macros and G commands.
I would like to code a simple scale factor into the move commands that will reference a settable variable. This is similar to the M579 command in RepRap controllers. I use M579 to deal with X/Y and Z shrinkage on prints with a delta printer, but I imagine it would be useful for all printers. If i need to adjust shrinkage it is a simple 1 line change in the file to reprint. (I have had shrinkage vary based on day…)
I would imagine this scale factor should modify the commanded motions prior to the implementation of the kinematics model similar to GCODE_OFFSET.
Is this something that is already coded? I did not see anything in gcode_move.py, really its a M221 for your axis steppers. ^^
I will just hack this into the for loop in G1 with no checks for machine limits etc since the value is usually low, (97% to 103%) but curious if its something others would use such that like GCODE_OFFSET it makes sure the base and homing properties are updated and can be config saved.
I have zero python experience (old Java person) and don’t know if I could quickly make a pull request if someone else wants to pick up this torch I will be supportive. ^^
1.) Scale axis similar to cmd_M221
2.) Scale machine bounds by similar factor and save.
3.) (Maybe) Add new machine variables that are stored in config file.
Assuming you could do what you attempt to do, this would result in a change of the rotation distance. So not the dimensions of the model would change, also the position on the print area, aka layer shifts.
To compensate that, you have to take care of the position of the model on the print area and include that into the position data of the move commands. And that gets way more complicated if you have more than one model on the bed.
If the dimensions vary during print, something is not quite stable with the printer.
If it is shrinkage of the material, you should set this factor inside the slicer.
Correct on a Cartesian kinematic setup it would “look like” a modification to the rotational distance. Changing this wildly during a print is a good way to make spaghetti. This should only changed during start-up part of your g-code file, else you would get strange layer shifts. Although if you had this command you could print a material test cube that varies the X/Y to give you the scale factor needed for shrinkage per material and nozzle temperature… hmmm that might be another idea…
I could see issues with people that have tool changers or some sort of target outsized of the printable bound that changing scale factor would cause issues. Its also feature you need to shut off when leveling which is what most bed.g macros do on a RepRap.
For model positions that wont be an issue. You are scaling a factor from the origin to the max position of your gcode in the model. The only issue is if you are printing to the very max of your printers dimension and a scale factor causes you to exceed your machine limits.
Agreed. I have dimensional variations not with the tool head position but with the part itself after material cooling. Where even the age of the filament, weather, and material can vary shrinkage by 1%.
That is what I used to do in the past but with Cura its easy to forget that you are PETG not PLA and needed a different scale during prepare since there is not a “shrinkage” variable for the material. Since my RepRap I would just know what values to use for my M579 command. Also if you keep your shrinkage factor outside your slicer you don’t need to go back and re-slice if you change material you can just update your temp, flow rate, and scale factor. Great for a print you did a year ago in PLA and should have done in PETG and only have the g-code file… Currently for a non-RepRap I have to load my g-code in Universal Gcode Sender program and scale it there.
In most cases, rotation_distances should be kept at the values defined by the hardware specifications. They shouldn’t require “calibration”, and are not the right knob to adjust for shrinkage compensation. As you pointed out, this would not work with non cartesian kinematics.
The better solution is to use slicer’s X/Y expansion, or part scaling.
Compensating shrinkage with axis scaling would result in under-extrusion if the flow is not adjusted accordingly. When the compensation is done by the slicer, it knows that it have to lay down more material.
Small sample size but looks like my tool chain of just scaling the gcode like i would for milling is heresy to most and they have better luck with their slicers.
I did find a much simpler solution for me since all I own are deltas. I will simply spoof new values for delta calibration advance based on an excel i made to vary my global scaling. I will probably just code this into a macro and keep a backup of my baseline delta_calibrates if i accidentally perform a save_config.
This will also let me add a start code macro based on material type for shrinkage and flow off my baseline PLA values. I can have the calibrate chug away while the bed heats up.
Super impressed with the delta advanced calibrated my PLA baseline profiles are getting 74mm +/-.05 and that is crazy to me. I am happy to get to +/-0.10 on my RepRap. I was 20 thou over on average with low deviation after my first calibration but that is when i decided to spoof a advance calibration that would just global scale and i got to my great baseline.
I have never cranked my rod end distance to what the auto calibrate did but man it works for my setup. Great job Klipper delta calibration team.