Hy,
since the last update suggested in fluidd yesterday, it was os-packages, moonraker, klipper…
i have the same issue and fault message from my tmc5160 z-driver, before update had the tmc failaure never!, nothing changed in this area of z-driver, cables, motor or so…
Also got a new failure message till z-homing:
Failed to home z: Timeout during homing
Seems like some strange behavior of the communication with the TMC5160drivers?
I hope you can help me, it looks for me like voodo, don`t what would right.
May be i should make a firmware reflash after the new klipper update?
Update:
Because of using high geared(28:1) steppers for Z i have a low z-travel-speed of max. 1.5mm/s.
The interest is now, if i have homing z with 1.5mm/s i get this tmc-failure when the probe triggers and also the message Failed to home z: Timeout during homing, this timeout message comes also after some mm when zprobe don´t trigger, when i start z at higher point, e.g. z…10mm…
But when i home z with 1mm/s, and have travel with 1.5mm/s all worked normal!?
Update:
Tested with homing z with 1.4mm/s worked, if i go to 1.45mm/s it worked the first homing and throws the known tmc failure in second homing… looked like something goes wrong with the speeds at homing proccedure script?
Problem is i need fast homing for piezo-probe… and it doesn`t make seens for me why it worked with 1.4mm/s and with 1.5mm/s not? I would prefer to understand this behavior;-)
have also log files of this… but don`t know where to upload here?
Maybe need to know System is a skr1.3 with xyz tmc5160 and extruder tmc2130 on 24v tmc params generated with calculation-excel sheet and also a lot of verifining the params…
Hope can help me to understand this behavior…
Best regards
Marco
So, have made several tests and the behavior looks strange…
Have checked my params and tried litely changed params no change of behavior, if i disable stealth the tmc-fault comes directly…
also were´s the benefit of the tmc´s if i disable stealthchop, its to loud! and have no issues with it since now…
If i go on default TMC-settings the error comes earlier of Bed-mesh probe points, Homing works!
BUT the strange thing is the error comes togehter with a “Timeout” message after probe triggered!?
I also thought the tmc error could be right because of maybe high force from the piezo probing to the stepper, but thats not! Maybe its a problem of retract acceleration and backlash from the geared Stepper (28:1).
Homing works now, but sometimes after several probings (10-12point) in BED-Mesh comes the tmc-error! Have changed the z-acceleration to 6mm/s² and lowered stealthchop 5
Edit:
Have lowered the run_current from 2A to 1.8A, now it probe bed_mesh without faulty message and my old tmc-z-params!?
What appears to be happening here is that the TMC drivers aren’t able to make good stealthchop current predictions - to the point that it sends so much current through the motor that it triggers its own over-current detection. I’ve updated the docs to mention this ( https://www.klipper3d.org/TMC_Drivers.html#why-did-i-get-a-tmc-reports-error–error ).
The obvious question is - why are the drivers now making poor stealthchop predictions when they weren’t before? Alas, I don’t know why that would be. It does appear the code is correctly detecting the error once it occurs, so it is not a problem due to the new error detection code.
One thing you could try is:
Remove all the driver_xxx settings from the config.
Go back to an earlier Klipper version that didn’t show the problem. Run DUMP_TMC on the driver motors before running Z_TILT_ADJUST. Go through the z_tilt sequence. Run DUMP_TMC on the driver motors after the sequence completes - I’m particularly interested in the PWMCONF results. Upload the full Klipper log file here.
Return to the master branch and run the tests again.
See some posts above, you have already done this. The mentioned commit is before the work on the TMC started.
Also you have proven that the error does not happen with this commit, so it should do what Kevin is asking for.
The second log should have shown that if I do Z_TILT_ADJUST directly after homing with physical load the error why I opened this thread occurs… should because I made a mistake.
Accidentally I switchted the position of the G1 line, so it’s now before the Z_TILT_ADJUST line. Well funnily everything works immediatly with this configuration.
I have done several tests and made all of it log.files with dump_tmc before and after errors.
So for me it looks like especialy the TMC5160 seems to be very sensitive on its Basic initial settings! Before, i had TMC2130 and all works perfect with stock settings.
I`ve build up my printer with 24V350W Supply, Nema17 steppers with 2.1A on XY and 2xparallel Nema17 Geared28:1, all newly with TMC5160 V1.2 active cooled…
And then it began… with the stock params for the 5160 the XY steppers got really hot! So i corrected some params of the settings, i got it from the tmc5160calculation excel-sheet and made a lot of testing of these params of printing and temperature and noises, till perfect stepper temp, that affected only the xy.
Then i changed to piezo probe and had to increase the probe speed from 1mm/s to 1,4mm/s and then i`ve got these error message from the Z-TMC with 2A current_rate, Stock settings throws the error only earlier! When i disable stealthchop it throws then the message undervoltage?
After i changed the Current to 1.8A for the Z-TMC and activate stealthchop mode all works fine, Homing, screws_Tilt, Bed_mesh.
But the interesting is, this sytem seems to work properly but if i check dump_tmc before first homing it says uv_cp=1(Undervoltage!) but homing and all works fine!?
So i think the TMC-Error detection from the Software works proper but the TMC5160 react really sensitive on its params and need individiual optimisation of it and thats difficult i changed only toff, hstrt, hend, and it seems after i see the undervolt message at intial, there is some more!?
Thank you for your help:-)
I hope these datas from my printer are helpful for analyze?
-Marco
Sorry, can`t upload the files instead… not reached level
so here it is TMC_ISSUES_HYPB_MWE.zip (265.5 KB)
have you tried lowering steprate to 8bit microstep, because the tmc automatically interpolate and you have 400 step motors! Maybe you are overstepped;-) with this inital params for the 5160 at initializing? i have high geared steppers on my z-axis and gone down to 1bit microstep in settings till it all worked properly…
The same config worked for 2 years until I opened this thread. Z needs even more steps and works also. A G1 before Z_TILT_Adjust solves the problem for me. G28 and directly Z_TILT_Adjust afterwards triggers the problem.
Ultimately, it seems the problem is that the tmc5160 is making bad stealthchop predictions and is triggering its own over-current detection.
I noticed you have calls to INIT_TMC in your macros. These should be removed. The latest version of Klipper will automatically resend the init sequence each time the driver is enabled. I suspect the extra INIT_TMC sequences may be resetting the driver’s stealthchop predictions.
I suspect adding the G1 move improves your results because it gives the driver more movement data to build its stealthchop predictions.
Thank you Kevin for your fast answer.
Sadly removing the INIT_TMC in my macros was not solving the problem.
After this attempt I tried a dummy G1 (G1 to the Z-homing-position where it already is when this command is called) which doesn’t cause any movement. This attempt also failed.
Afterwards I went back to a G1 moving the printer to the first Z_TILT_ADJUST position, than everything worked.
Here’s the log of this session: klippy.log (633.5 KB)
