Without any help -> Y driver error detected:

[hevilp]

Hi,

today I got the error below, where is there error? No ground, no heat, just nothing that helps. It worked for many weeks flawless

< 23:00:36.307: N238737 G1 X178.735 Y79.622 E15.5415
> 23:00:36.357: ok
< 23:00:36.357: N238738 G1 X180.470 Y80.700 E15.6409
> 23:00:36.407: ok
< 23:00:36.407: N238739 G1 X181.060 Y81.036 E15.6739
> 23:00:36.415: Y driver error detected:
> 23:00:36.418:   X Y E0
> 23:00:36.418: Enabled  true true true
> 23:00:36.419: Set current 800 800 500
> 23:00:36.422: RMS current 795 795 489
> 23:00:36.423: MAX current 1121 1121 689
> 23:00:36.425: Run current 25/31 25/31 15/31
> 23:00:36.426: Hold current 12/31 12/31 7/31
> 23:00:36.426: CS actual  25/31 25/31 15/31
> 23:00:36.429: PWM scale 53 82 29
> 23:00:36.430: vsense  1=.18 1=.18 1=.18
> 23:00:36.432: stealthChop true true true
> 23:00:36.432: msteps  16 16 16
> 23:00:36.433: tstep  265 2110 1617
> 23:00:36.433: pwm
> 23:00:36.436: threshold  98 98 95
> 23:00:36.436: [mm/s]  100.85 100.85 30.04
> 23:00:36.437: OT prewarn false false false
> 23:00:36.438: OT prewarn has
> 23:00:36.440: been triggered false false false
> 23:00:36.440: off time  5 5 5
> 23:00:36.441: blank time 24 24 24
> 23:00:36.441: hysterisis
> 23:00:36.442: -end  2 2 2
> 23:00:36.443: -start  3 3 3
> 23:00:36.444: Stallguard thrs 0 0 0
> 23:00:36.444: DRVSTATUS X Y E0
> 23:00:36.445: stallguard    
> 23:00:36.445: sg_result  0 0 0
> 23:00:36.448: fsactive    
> 23:00:36.448: stst    
> 23:00:36.448: olb    
> 23:00:36.449: ola    
> 23:00:36.449: s2gb    
> 23:00:36.449: s2ga    
> 23:00:36.450: otpw    
> 23:00:36.451: ot    
> 23:00:36.451: Driver registers:
> 23:00:36.452:  X = 0x00:19:00:00
> 23:00:36.452:  Y = 0x00:19:00:00
> 23:00:36.453:  E0 = 0x00:0F:00:00
> 23:00:36.456: Firmware was halted, trying to reconnect. Eventually running print is stopped.

[teemuatlut]

Marlin will react to whatever the response from the driver is. Either the response is legit and you have a problem and the driver reported it as such. Or maybe you have a weird wiring issue and the message received is not actually the one the driver sent. However, if you believe that the error is false, you can disable STOP_ON_ERROR and Marlin will try to continue printing, no matter if the drivers are still enabled or not. This feature was implemented so that when a driver turns itself off when trying to protect itself, Marlin can know about it and stop the print to save time and material is not wasted on a failed print.

[hevilp]

I checked the wire and all is fine. I checked the cooling and all is fine. Sometimes there is no error, sometimes there comes overheat and then the shutdown. Its weird, because now it happens on the x stepper driver and on the y , not to reproduce...

I changed from bowden to direct drive, maybe it is to heavy and the tmc2130 have to work more? I dont know...

[hevilp]

Hi again,

I think I figured out, that the part #define MONITOR_DRIVER_STATUS is the problem. it is not enough to disable #define STOP_ON_ERROR. With disabled MONITOR_DRIVER_STATUS I can print without problems, so far. Your debugging version of Marlin changed there something?

[teemuatlut]

MONITOR_DRIVER_STATUS is the option that starts checking on the driver. STOP_ON_ERROR is what defines what Marlin will do with an error condition.

Yes, I did change things.

[hevilp]

Okay, but I disabled the STOP_ON_ERROR and the print fails. I disabled the whole MONITOR_DRIVER_STATUS, so it cannot only be the STOP_ON_ERROR or?

[teemuatlut]

I need to know more than "print fails". There's only one kill command in the monitoring logic and that is behind STOP_ON_ERROR condition.

[hevilp]

Often there was overheat, but I got 2 fans for 3 TMC2130, so I'm sure that is not overheating. Like I said, only to disable STOP_ON_ERROR is not enough. Maybe the part with decrease the current makes trouble?

[teemuatlut]

So the print didn't actually stop with a kill message? It doesn't matter if you have two or twenty fans. You can still produce enough heat to trigger the OTPW flag.

[hevilp]

Acutally, the only workaround not to fail longer prints with a kill message, is to disable MONITOR_DRIVER_STATUS. With enabled MONITOR_DRIVER_STATUS and disabled STOP_ON_ERROR it dies with Y driver error detected: or Y driver error detected: overheat (or mostly X, it doesn't matter).

For my next print I will use your debug branch with both enabled .

[teemuatlut]

Could you recompile with STOP_ON_ERROR disabled? There simply should be no way for Marlin to be able to kill the print if the code doesn't get included during compile time.

Also just checking, you're using the bf2_TMC_debug_update branch?

[hevilp]

I use the official github 2.x.x branch from last friday. There I could compile without disable STOP_ON_ERROR Tomorrow, after the current print, I will use your bf2_TMC_debug_update.

Should I disable STOP_ON_ERROR then?

[teemuatlut]

If you want.

This feature was implemented so that when a driver turns itself off when trying to protect itself, Marlin can know about it and stop the print to save time and material is not wasted on a failed print.

[hevilp]

What is the reason for the overheat? the current specified? or something more?

[teemuatlut]

Current, chopper frequency, other internal losses. Mainly it's the current.

[hevilp]

I ask, because I had 500 mA and still got overheat problems, but I think there are reporting errors, we will see...