Hi I got the problem that my printer crashes with the following message “!! TMC ‘stepper_y’ reports error: DRV_STATUS: 801f5000 s2vsa=1 stealth=1 CSACTUAL=31 stst=1”, checking the errorcode s2vsa=1 indicates that there’s a short circuit somewhere. I checked TMC 5160 driver and motor by replacing them with spare parts. This changed nothing. For me it’s looking like some software issue.
I did the following steps before posting:
Checking motor and wiring with multimeter
Replacing motor, TMC 5160 and wiring with spare parts
Checking TMC 5160 before the error with DUMP_TMC Stepper= stepper_y
I’m able to do homing and random manual moves using G1 as often and long as I want and no errors occur.
When using Z_TILT_ADJUST it’s moving to the first probing point and before triggering it crashes with “!! TMC ‘stepper_y’ reports error: DRV_STATUS: 801f5000 s2vsa=1 stealth=1 CSACTUAL=31 stst=1”
Step 3 and 4 are reproduceable.
I did not replace SKR Pro 1.1, as I think a damaged board would be more likely produce capital errors.
What I did before the error occured:
I added ADXL345 follwing the steps mentioned here Measuring_Resonances.html and here RPi_microcontroller.html
Thx for the answer! I switched off all driver_*'s except stallguard as I use it for homing. Those settings where suggested in a example*.cfg, it worked for me since 8 months.
I also forced spreadcycle by stealthchop_threshold = 0 as you mentioned, than everything works.
After activating stealthchop again Z_TILT_ADJUST fails again as described above.
I don’t understand why this happens after installing ADXL345 (I followed this guide Measuring Resonances | klipper), I don’t have changed anything else except this part in printer.cfg, I never had issues like this before. Even I don’t understand why Z-homing is working, which is basicly the same probing procedure in my amateur eyes.
This is quite interesting.
I had a similar issue on my SKR 1.4T and TMC2209: With activated stealth-chop suddenly my Y driver would throw an error message.
The really strange thing is that once I forced it to spread-cycle, do some moves and then back to stealth-chop the error would go away.
For me this started with the rework of the TMC functions / improvement of error reporting around the 20th of February this year.
But on my side, the error was very sporadic and happened maybe 3 times. For quite some times it didn’t come back now, that is why I never bothered to report it.
I also have connected an ADXL but I never checked if there is any coincidence with this error.
Wooohoo wtf. I don’t know which coordinates it is using while doing Z_TILT_ADJUST, but it was probing somehow and didn’t crash anything, even with stealthchop switched on. But the coordinates were scary…
EDIT: Going back to actual build and flashfile results in first post of me in this topic.
No, the coordinates are somehow screwed up. I guess my printer.cfg is not working right with the old commit. But probing works for Z_TILT_ADJUST, it doesn’t lead to a driver crash.
I will use a second SD Card and make a Installation without the adxl345 stuff…
I would recommend not to mix two different issues. Probing and driver communication should not be related.
Are your drivers working without error message when going back to the above mentioned commit? If yes, it is reliable and reproducible?
Yes it is. The second issue (coordinates) you mentioned is not a real issue for me, as I blame the acutal printer.cfg not working with an older commit.
Nevertheless, SPI is Working, TMC5160s don’t have an standalone mode, I can switch from stealthchop to stealthchop off and vice versa. The power settings are also working.
What I don’t understand is the follwing error for all drivers/motors: TMC stepper_x failed to init: Unable to write tmc spi 'stepper_x' register GLOBALSCALER
Further I did some testing, the problem exists if either tmc5160 stepper_x or tmc5160 stepper_y or both have activated stealthchop. Stealthchop on tmc5160 stepper_z* doesn’t influence the problem.
The drivers are fine (I switched 2z’s to x and y, and x/y to z’s), the motors are fine and I replaced the mainboard.
The printer still crashes with !! TMC 'stepper_y' reports error: DRV_STATUS: 801c5000 s2vsa=1 stealth=1 CSACTUAL=28 stst=1 when stealthchop is activated, if it’s switched off there are no errors.
I don’t know why, somehow I think there’s a bug, because probing while homing Z works without problems, the same probing procedure with Z_TILT_ADJUST and I get reliable and reproducible an error.
Even I can do random G1’s with random feedrates and there’s no problem.
With the current Klipper version, you get the error message !! TMC 'stepper_y' reports error: DRV_STATUS: 801c5000 s2vsa=1 stealth=1 CSACTUAL=28 stst=1 when stealth-chop is enabled. Disabling stealth-chop will “solve” the error
Going back to commit 4d2adddb202321cd4f65e41b9ffe6fac5d1fe566 will allow both stealth-chop and spread-cycle to work without problems
I have noticed a similar behavior on my SKR1.4T with TMC2209, although on my setup it is hard to reproduce. Cycling from spread-cycle “on” to spread-cycle “off” did more or less cure the problem on the 3 instances I had it. On my side it only affected the y-axis in all cases. My first contact with this phenomenon was also after updating to a Klipper version with the TMC rework (after the a.m. commit)
If this summary is correct, then I guess we have more or less done what we can do. @koconnor anything we could do to tackle this further?
That’s certainly odd. The driver is indicating it has disabled itself - from the tmc5160 spec: Short to supply detected on phase A or B. The driver becomes disabled. The flags stay active, until the driver is disabled by software (TOFF=0) or by the ENN input. Sense resistor voltage drop is included in the measurement!
One test you can run is to edit the file klippy/extras/tmc.py , find the two lines that look like:
(That is, make Klipper report the short-circuit detection as a warning instead of as an error.) Make sure to keep the indentation of those lines otherwise unchanged. After making the change, the software needs a full restart via sudo service klipper restart . Then run the Z_TILT_ADJUST again and see what it does.
Now I’m getting the follwing message: !! TMC 'stepper_y' reports error: GSTAT: 00000002 drv_err=1(ErrorShutdown!)
And now why this is relly weird… I’ve removed the XY-motors out of my printer, and did the same Z_TILT_ADJUST (the Z’s are still in their real position and moving the bed up and down) and everything works. Putting them back in their working position with belts, results in !! TMC 'stepper_y' reports error: GSTAT: 00000002 drv_err=1(ErrorShutdown!).
While writing this lines I did the following experiment…
I loosened the belts so the XY-motors turn without any load, the xy-gantry isn’t moving than.
I did homing like I always do, triggered stallguard with my fingers.
I did Z_TITLT_ADJUST
Wonder, nothing to adjust and no errors were raised.
DUMP_TMC Stepper=stepper_* (with all 5 movement related stepper drivers)
I tightened the belts so the motors are connected to the gantry
M84 to be able to move the attached XY-gantry freely
Fired my intial script ===> homing ==> Z_TITLT_ADJUST
WTF it works, same components as all the time.
Z_TILT_ADJUST, has been running 2 rounds and leveled the bed.
Again I did DUMP_TMC for all movement related steppers/drivers.
I copied moonraker.log & klippy.log after this whole session, perhaps it’s good for something.
==> klippy.log
As I am a man of science and support, I went for a FIRMWARE_RESTART to look what happens and funnily everything’s still fine, again Z_TILT_ADJUST ran 2 rounds, and bed is leveled.
Pushing it further I did RESTART, also works.
After powering off everything, with the power switch using my intial script again… well…: !! TMC 'stepper_y' reports error: GSTAT: 00000002 drv_err=1(ErrorShutdown!)
I also have klippy.log of this session. ==> klippy.log
Interesting. That seems to confirm the driver is in fact shutting itself down.
Could you try one more test - return to the unmodified code and then on line 255 of klippy/extras/tmc.py, change the line that says self._init_registers() to #self._init_registers(). (That is, comment out the call to the init register function in the _do_enable() method.) After changing the code, make sure to run sudo service klipper restart to restart the software.
Correct me if I did something wrong… I only changed back to “original” tmc.py and modified it in line 255 from self._init_registers() to #self._init_registers().
I don’t know which coordinates it is using while doing 