Slug trails -- still getting constant extrusion w/ RC4; ever give up on crash recovery?
I've got 'slug trails' in about three prints, over a few revisions of firmware and this time I caught it in the act. A test Buddy I sliced started drifting off to the corner; it appears to be just extruding filament and rather slowly drifting down-and-to-the-right, at a constant speed. Sliced with 2.1.1 software, running on 3.1.1 RC4 firmware, operated from OctoPrint on the internal port. The log seemed to show nothing lively, it seemed to just be 'busy: processing' at the time. It finally gave up on the slug trail once it went outside print bounds, looked like it triggered crash recovery, and then picked up back on the main print.
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: ok
Send: N7206 M105*20
Recv: ok T:210.0 /210.0 B:60.1 /60.0 T0:210.0 /210.0 @:64 B@:48 P:35.0 A:34.5
Send: N7207 G1 X131.232 Y123.479 E0.00295*84
Recv: echo:busy: processing
Recv: echo:busy: processing
Separately, does it ever give up on crash recovery? I watched it try and print, slam into the slug trail, and try and recover around five times before I reset the poor thing. Anyone know whether there's a total-recovery count (if not, hint, it would be a good safety feature, maybe maximum N recoveries in M time, to avoid penalizing longer prints).
(Yes, I forgot to clean off the calibration; you should always clean off the bed before printing. 🙂