Extruder motor/ Z axis issue

General Discussion
1

Im having an issue that I am finding difficult to track down. I have a custom built corexy printer and when I move my z axis I believe my extruder motor is kicking in as well and making a grinding sound. I can move my x and y axis without this issue, as soon as I home my dual z axis the extruder starts grinding and will not stop until I shut off all the motors.

I just updated my klipper instance and I am almost positive that this was not an issue before the update, but don’t have anyway to downgrade my version back to where it was before and confirm.

If my log has any information in it that can help I don’t have enough experience to understand what it is telling me.

Thanks for any and all help.
klippy.log (846.9 KB)

2

Does anyone have any steps I could take, or ideas? I’d appreciate anything at all just to hopefully get me in the right direction. Or if anyone has details on how to go to an older version of clipper I’d love that info as well. Thanks!

3 
TMC 'stepper_z' reports GSTAT:      00000001 reset=1(Reset)
TMC 'stepper_z1' reports GSTAT:      00000001 reset=1(Reset)
TMC 'stepper_z' reports GSTAT:      00000000
TMC 'stepper_z1' reports GSTAT:      00000000
Stats 9981.3: gcodein=34  mcu: mcu_awake=0.005 mcu_task_avg=0.000007 mcu_task_stddev=0.000007 bytes_write=4179 bytes_read=7818 bytes_retransmit=9 bytes_invalid=0 send_seq=310 receive_seq=310 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=180003320  heater_bed: target=0 temp=23.2 pwm=0.000 sysload=0.44 cputime=74.180 memavail=560336 print_time=35.412 buffer_time=0.000 print_stall=0 extruder: target=0 temp=23.1 pwm=0.000
Stats 9982.3: gcodein=34  mcu: mcu_awake=0.005 mcu_task_avg=0.000007 mcu_task_stddev=0.000007 bytes_write=4241 bytes_read=8031 bytes_retransmit=9 bytes_invalid=0 send_seq=315 receive_seq=315 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=180003162  heater_bed: target=0 temp=23.4 pwm=0.000 sysload=0.44 cputime=74.206 memavail=560036 print_time=35.412 buffer_time=0.000 print_stall=0 extruder: target=0 temp=23.2 pwm=0.000
Stats 9983.3: gcodein=34  mcu: mcu_awake=0.002 mcu_task_avg=0.000006 mcu_task_stddev=0.000005 bytes_write=5006 bytes_read=8853 bytes_retransmit=9 bytes_invalid=0 send_seq=358 receive_seq=358 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=180002987  heater_bed: target=0 temp=23.4 pwm=0.000 sysload=0.44 cputime=74.273 memavail=560132 print_time=35.612 buffer_time=0.000 print_stall=0 extruder: target=0 temp=23.1 pwm=0.000
TMC 'stepper_y' reports GSTAT:      00000001 reset=1(Reset)
TMC 'stepper_x' reports GSTAT:      00000001 reset=1(Reset)
TMC 'stepper_y' reports GSTAT:      00000000
TMC 'stepper_x' reports GSTAT:      00000000

TMC 'stepper_z1' reports DRV_STATUS: 00190090 s2vsa=1(LowSideShort_A!) olb=1(OpenLoad_B!) cs_actual=25
Transition to shutdown state: TMC 'stepper_z1' reports error: DRV_STATUS: 00190090 s2vsa=1(LowSideShort_A!) olb=1(OpenLoad_B!) cs_actual=25

See: TMC 'extruder' reports error: GSTAT: 00000001 reset=1(reset - #39 by Sineos

4

I will definitely look into this, wiring and components are always possible. I appreciate the link!

5

Note that not Klipper is generating these errors. The TMC driver modules are generating these fault messages and Klipper is reacting upon them with a hard stop.

Unfortunately experience has shown that also basically unrelated components like a defect endstop can cause such fault messages in the TMC modules.
This means even if you do not find anything apparent, there is still something going on that is causing your TMC modules to go into an error state. Marlin ignores them, which I personally think is not the right thing to do.

6

Thanks for you help Sineos! You got my brain on a different track and that was enough.

Essentially my issue was much deeper than just the extruder vibrating (which was simply a loose cable on my hermit crab quick tool changer) I was trying to run dual z on a BTT octopus and I have worked with boards that have a z_1 and z_2 but did not connect that even though this board has 8 drivers it has 9 motor connectors (the ninth is added for a mirrored dual z)

So to sum up my mistake I had my extruder setup correctly in my config for driver #3 but I was plugging the extruder into driver #2 and my second z stepper plugged into z_2. This is what caused them all to be synced together instead of each motor having their own driver.

My experience of making completely avoidable mistakes have not sunk in yet…, But I’m hopeful that this experience sinks in.