Alas, I don’t know why the tmc drivers are disabling themselves.
It’s certainly odd that this used to work - I can’t think of any Klipper change that would alter how the drivers implement stealthchop.
If you’d like to track it down, the next step would be to run a git bisect session to find the exact commit that introduced the change in behaviour. (There should be various guides online describing how to run git bisect.) Use the same config for all attempts, and use a simple config (no INIT_TMC and no driver_XXX settings).
Otherwise, it sounds like you’ve found a simple workaround.
I also had my eyes on the commits happened between 27.03.2021 and 19.04.2021, between this time I rebuilded my printer. On March 27th I’ve done the last klipper update before the rebuild. The printers hardware is still the same as before but the design of gantry and bed changed a lot. I also can’t guess what would be causing this mess. On 19.04.2021 I added the adxl345, I checked the basic functions before that, also Z_TILT_ADJUST and BED_MESH_CALIBRATE. I simply had to change the bed and probe coordinates nothing else.
Could it be possible that the ADXL345 hardware itself, which is all the time connected to the raspberry pi since this moment I added it, is causing some interferences to the TMC5160 which is on the SKR Pro 1.1? I mean both is connected via SPI. But they’re more than 30cm away from each other, which would be quite alot for such interferences. I made the SPI-Cable for the ADXL345 by myself, it has no cable shielding, but it works quite well.
EDIT 1: I just looked at the back of my printer and saw that the ADXL345-cables are directly above the Y_TMC5160, after my actual print is finished I’ll have a look.
EDIT 2: Sadly the ADXL345 didn’t cause the problems.
@Sineos@koconnor
I found out switching extruder port on SKR Pro 1.1 with stepper_y port solves the problem (and of course I updated the printer.cfg). I don’t need any G1, afterwards I also changed the drivers so the “old” driver_y is now in the extruder driver socket and the extruder driver is now on the motor_y socket. Well it works I have no idea, the same drivers and motors are working together. This would mean both SKR Pro 1.1 would be faulty and it would be exactly the same error 2x.
If I find some spare time I’ll do the git bisect thing.
I too just started having this issue after replacing my TMC5160 drivers that I’ve been using successfully for 18+ months with the updated TMC5160A drivers. Trinamic issued a bulletin on their website last year that explained how the ‘A’ revision of their drivers corrects a stealthchop defect that’s been present in their drivers since day one. Their plan was to introduce the ‘A’ revision into the distribution channel when their stock of existing non ‘A’ revision silicon was exhausted. One poster above mentioned that he’s now seeing this issue on a printer with BTT v1.2 TMC5160 drivers. BTT is using the TMC5160A on their v1.2 stepsticks and I suspect the new Trinamic silicon was the main reason BTT released the 1.2 revision. Lastly, the ‘A’ revision was performed on all Trinamic drivers that use stealthchop, not just the 5160.
I just stumbled across this thread while trying to troubleshoot this same issue on my printer and haven’t had a chance to look into the TMC related changes that were made to Klipper earlier this year (in Feb??)
@koconnor, knowing that I haven’t looked into the TMC changes to Klipper made earlier this year, it’s looking like there needs to be two code paths toggled with a printer.cfg entry that would allow the current Klipper TMC code to be used with NON rev ‘A’ silicon and then the code prior to the TMC changes earlier this year would be used with rev ‘A’ Trinamic silicon.
I’ll test my suspicion by swapping my 5160A drivers with my older 5160 drivers and report back.
Actually I do not think that this is the root cause. I have sporadically seen the same behavior on my TMC2209 and the hardware improvement seems only applicable to the TMCx160 line.
Fair enough on the rev ‘A’ applicability, I was going from memory of the bulletin. Looks like I misremembered the timeframe of the change, too. Trinamic rev’d the drivers in late 2019, not 2020. Also, it appears that the TMC5130 was rev’d in addition to TMCx160 line.
Applicability and timeframe of revision aside…I swapped out my TMC5160A drivers with TMC5160 drivers without recompiling Klipper and I’m not experiencing driver shutdown when homing or performing a Z tilt adjust.
I have also had TMC5160 driver issues since upgrading to Klipper 0.10.0 from 0.9.0. Biggest changes I noticed is that when homing, if I don’t set a hold current quite low, the steppers will have a high pitched whine, before I had the hold current same as run current, both fairly low.
I have an SKR pro with step_pulse_duration: 0.0 for all steppers, 24V system, I run the X Y steppers at 128 microsteps, and I have 0.9 deg steppers on X Y. I have a large print area, and I have my travel speed set to 600 mm/s, which has been working fine. You could say I am max performing my hardware. I have resonance compensation with MZV shaper on both axes and accel 4000. If I up the accel with steppers in stealthchop, I will also get TMC driver errors occasionally and a canceled print. I’ve tried increasing the currents, this helped some but not a cure. Can I not have fast travel speeds and high accels with stealtchop? Input shaper says I can do up to 9600 accel. I do have max_accel_to_decel=max_accel, it seems increasing max_accel_to_decel is what causes the TMC errors. Perhaps I can increase regular accel but not max_accel_to_decel? I have noticed that the first move usually causes the issue, then the rest of the print will continue normally.
Also, there is sometimes a clunk of sorts that happens on the first move, sometimes for homing and then also the first move in the print. Perhaps the modes are changing from spreadcycle to stealthchop on the move? If I remember right, homing is done in spreadcycle, so then if I have stealthchop_threshold: 999999 to enable it, perhaps the switch should happen between homing and starting the print with some kind of pause? Maybe the clunk when starting homing is from stealthchop being on from the last print, but then needing to switch to spreadcycle for homing? Log attached. klippy.log (3.8 MB)