Using this macro: Determining Maximum Speeds and Accelerations | Ellis’ Print Tuning Guide I used to be able to get “mcu: stepper_x/y” in 16 microsteps differences. Now, I have a huge variation of hundreds to thousands of steps, no matter how low I go in speed/accel. @dmbutyugin hope it’s fine tagging you, maybe you have some info.
The Klipper install is dirty: The "dirty" Flag and the Team's Position. Autotune directly influences the motor behaviour.
You may try with a pristine Klipper setup.
I can assure you this is done with the latest version of klipper, I just keep a seperate repo that I maintain which can be found here: GitHub - celtare21/klipper: Klipper is a 3d-printer firmware. For our sake, it is mostly 1:1 with the normal klipper repo.
I’ve also tried to disable autotune completely and nothing changed.
What we’re asking is if you can try this procedure on mainline Klipper. Your Klipper version has quite a few changes in the input shaping and step generation code.
BTW, you likely don’t need your custom probe_as_z_home functionality. You can do the same thing with homing_override and using PROBE to home Z.
No worries. If needed I can try to compile before and after, I asked a friend that hasn’t updated yet to also try. The thing I know for sure is that I never had more than ±16. At most ±20 if I was skipping very few steps, but never 1000+. It’s a test I run quite often, it’s part of my calibration routine to make sure the printer is in good parameters. I don’t know if it shows a real regression in step accuracy or just the reporting of the steps
I have doubts about your max speed.
You set the speed to 600 mm/s, it looks like the motors are 0.9 degrees per full step.
Even on the normal ones, with 1.8 degrees TMC2209 with 24v power would have issues with speeds closer to 500mm/s.
You set your max speed and test speed as 600mm/s.
Which, for CoreXY, actually for diagonal moves, is: 600 * 1.44 = 864.0
So, if you think something is broken, I would suggest running the test at more adequate speeds, around 300 mm/s at least.
I can assure you they are more than capable enough to run at those speeds, I’ve been running them for years. They can go even higher. But sure, we can do an exercise and try lower speeds and accel. End result:
@celtare21 Well, I’m just unsure why you’d tag me - indeed there were many changes recently, but they were not by me for the most part. I’m unaware of any changes that would lead to position drifts, however. I can recommend a few things to check/try though:
Such a huge drift in mcu stepper positions that you report should be visible to the naked eye. What I mean is, after you move the printer, instead of homing, you could move the toolhead, say, G0 X0 Y0 and observe whether the location is expected or not - that is, do you see a noticeable deviation from 0, 0 typical position?
Instead of looking into mcu reported positions, you can instead test via `DUMP_TMC STEPPER=stepper_x and such and check MSCNT register values instead.
If nothing else, you could try git bisect to find the problematic commit. But if other tests do not indicate position drifts, perhaps the original assumption about reported MCU position being stable is (no longer) true without causing the actual issues? And I’m also unsure about how QUAD_GANTRY_LEVEL interacts with homing of different axes in various order (in the context of reported MCU positions).
Indeed, there have been some recent changes in this area of the code. I’ve seen this thread, but it is not clear to me what is being reported. (The report seems to be that the “mcu position” changes, but it’s not clear to me why that is unexpected.)
Maybe it would help if you could list the specific commands that you ran, the output that you received, and state the specific output you expected to see.
Also, I looked at the log above and at the TEST_SPEED macro definition. Be aware that the GET_POSITION mcu position report needs a full flush to obtain consistent results - use M400 for this (a G4 P1000 does not ensure a full flush). Code overview - Klipper documentation
