# Retraction fine but recovery occasionally just doesn't happen

I'm having issues with retraction. My printer prints very well normally, but has an intermittent problem with retraction: the retraction itself always happens, but sometimes the subsequent recovery just doesn't take place, which obviously results in gaps in the extrusion. I'm running out of diagnostics to try - can anyone suggest what might be causing this? I have:

• Removed the stepper from the extruder so it's free running
• Changed the driver board (to a newer design, although both are based on the TMC2130)
• Reseated all the connectors
• Switched off the driver's "StealthChop" function in favour of the fallback "SpreadCycle"
• Tried G-code produced in Prusa Slicer and known good code from Cura (taken from a retraction test put up on Thingiverse)
• Updated Marlin from 2.0.4.4 to 2.0.6.1

The machine is a Creality Ender 3, although the previous owner (who has reported no problems when he was using it; he's a friend, not an anonymous eBay seller) replaced the board with an MKS Gen L and the drivers with Big Tree Tech TMC2130s in SPI mode. The extruder stepper is the stock Creality model.

Other relevant settings:

• VRef on extruder driver is 0.875 V. As far as I can make out, the maximum suggested for these motors is 1.0 V
• Extruder current is firmware set to 900 mA
• Maximum feed rate for E is set in firmware to 25 mm/s, which I think is fairly low
• DEFAULT_MAX_ACCELERATION is set to 5000 mm/s2, but DEFAULT_RETRACT_ACCELERATION is set to 500 mm/s2 and (with no M204 instructions in the G-code) I would presume this takes precedence

I'm tearing my hair out here! Most of the changes I listed above had no effect, but I would say that the change to SpreadCycle for the driver reduced the occurrence and it seems to be more prevalent when the retraction distance is increased (4 mm is worse than 2 mm). The thing that's really confusing is the lack of symmetry - retractions always work, feeding forwards during printing always works, but feeding forwards during recovery sometimes doesn't - the stepper just doesn't turn.

I can increase the VRef or current, reduce the retraction speed and acceleration further and perhaps one of these will be the answer, but I'd like, ideally, to understand what's going wrong so I can target my fix. Does anyone have any ideas?

Edit

After comment discussion on overheating drivers, I measured a steady temperature of 77 °C with a thermistor pushed to the bottom of the stepper driver's heatsink fins. Is this expected or could it represent an overheating problem?

Edit 2

It turns out that the terminal is periodically printing a message indicating there may be a problem with the driver temperature (e.g. 2020-09-14 23:22:15,877 - Recv: 00:00: E driver overtemperature warning! (900mA)).

If there is a continuing problem, the stepper current should be throttled automatically, which is not happening. Nor is the actual overtemperature error condition being reached, because if this happened, the driver should completely shut down until it cools 25 °C and I believe Marlin should abandon the print at this point. Neither of these things seems to be happening, but perhaps the raised temperature is causing my stepper issues, nonetheless.

• As I understand, DEFAULT_RETRACT_ACCELERATION is only relevant if you're using firmware retraction (G10/G11). Normally I'd assume not (it's not in stock Ender 3 firmware), but since there's clearly custom firmware you could be - are you? Sep 14 '20 at 14:53
• No - retraction is done the old-school, slicer way. I hadn't realised this was only relevant for firmware retraction, but of course how would it know a move is retraction otherwise? DEFAULT_ACCELERATION is also set to 500, though, and I think that is relevant for all other moves that include an extruder parameter. If acceleration was set too high, could it cause long feed instructions to be completely, but intermittently ignored? Sep 14 '20 at 15:49
• I don't think so, at least not directly. Is it possible the E stepper driver is overheating from driving high-acceleration retracts/unretracts, which are high-load operations, and shutting down momentarily while it returns to operable temperature? Sep 14 '20 at 17:34
• Also, are the skipped recoveries entirely deterministic for a fixed gcode file? Or do they vary every time you print it? Sep 14 '20 at 17:35
• Overheating probably is a possibility. I haven't measured the driver temperature and although there is a case fan, ventilation is perhaps less than it could be. I'd thought the low current, speed limits and apparently more efficient chopping algorithms the TMC2130 uses might make this a lower possibility, but I also don't know how an overheating driver might behave: this might be a classic indication for all I know. If I can measure the temperature of the heatsink, what range might I be looking for to indicate a problem? Sep 14 '20 at 19:09