Firmware retraction bug - extruders stopping mid-print?

[Egosumumbravir]

Puzzling over this one.
Originally thought it was just the machine, but have now encountered the same fault on a second machine where the only real commonality between them is the MRiscoC firmware (and an Ender frame, but I reckon that doesn't count for much).

Environment
M1: 422 board, Sprite SE DD extruder, standard Sprite stepper, T5 NTC-100K (volcano) thermistor, Bambu rip-off hotend.
M2: 427 board, Red metal dual-gear bowden extruder, stock stepper, T13 high temp 100k 3950 thermistor, all metal hotend.
FW: Professional Firmware for 3D Printers 20231202. Custom compiled in both cases with BLT-UBL, DWIN, MPC, IS & LA - and firmware retractions.
SW: Orca Slicer 1.8, 1.9, 1.91 & Octoprint latest.

The fault - if fed GCODE generated with normal (G1 E-) retractions a some random point in the print the extruder simply stops extruding while the rest of the print proceeds as expected so I get mid-air nothing. Sometimes happens after 5 minutes, sometimes after 2 hours.
The stepper motor is locked & motionless; it's not even trying to extrude.
Very VERY sure it's NOT clogged or tangled. I can kill the print and as soon as the steppers unlock, manually advance filament through the cooling but still hot enough nozzle with no issues or real force required.

Issue occurs through both SD-card and Octoprint streamed files.

GCODE generated with firmware retractions (G10/G11) prints entirely as expected. Thus I wonder if there's a bug or compatibility issue with mixing GCODE retractions with FW retractions? Has anyone encountered anything like this before?

I hit this bug with the second machine feeding it a retraction tower so I can work out what to set for the FW retraction numbers.

Testing still to do

• grab the latest release (20240122) configure, compile & flash.
• Download Cura and reslice the model there.
• manually edit the Orca retraction tower to add M207/M208 lines as needed and test if M209 makes any difference.

[BEprints]

Interesting issue. Have you narrowed it down to just firmware retraction?

[mriscoc]

Check you Minimum Extruder Temperature.

[Egosumumbravir]

Interesting issue. Have you narrowed it down to just firmware retraction?

I'm not 100% sure if FW retractions are the cause or simply revealing the issue.

Check you Minimum Extruder Temperature.

180°C. 20°C under the current nozzle temperature.

Updates: since this issue seems to be easily triggered with an Orca retraction tower (it often doesn't even finish the base!) I went and grabbed one from TeachingTech - which printed to completion.
Then I loaded up Cura with the calibrations tower plugin - which also printed to completion.
Conclusion: something about Orca?
So I read the GCODE.
TT and Cura are both using absolute extrusion. Orca is configured to run relative.
Am just testing Orca code generated in absolute mode now.

[mriscoc]

Could be related to relative extrusion and LA: #999

[Egosumumbravir]

Could be related to relative extrusion and LA: #999

That's the kind of angle I've been wondering about. Perhaps more pervasive as it occurs on both 422 and 427 boards.
I've noticed that slicing for really fine (0.12 & 0.08) layer heights seems to trigger it more frequently.

Sadly, I've hit am impasse - after easily reproducing multiple times two days ago and yesterday with relative slices, then multiple successful absolute slices (Teaching Tech, Cura & Orca in ABS mode); this morning I've successfully completed a new REL slice and successfully rerun the failing REL gcode from the last two days.
Bah!
Nevertheless I'm going to configure Orca to only slice in absolute going forwards. LA is just too good to lose.

I might see if it triggers again in future. If I can, is there anything I can do to find out the stepper/driver status? Anything to help chase this one down?
Otherwise, I guess this is here for future reference. Absolute slicing boys and girls.

[Egosumumbravir]

Scratch that idea.
Tried a print-in-place gecko, Orca sliced for firmware retractions and absolute extrusions.
Worked great for about an hour, then extruder stopped again.

Following the link in that other thread to the Orbiter Apogee (https://www.orbiterprojects.com/apogee-ender-3-v2/), we find this note
"Using Creality silent board V4.2.7 or v4.2.2 we need to consider its limitations.

The major limitation is the hardwired stepper driver configuration. This do not allow disabling of stealth chopping feature.

When using stealth chopping the maximum stepper speed is limited. Trinamic suggests switching to spread cycle at high stepper speeds. You may think the extruder does not spin fast…but actually the Trinamic driver limitation is not stepper speed, but minimum step time. Having high step/mm ratio for the Orbiter v2.0, limits the maximum extrusion speed the Trinamic driver can drive the Orbiter to about 40mm/s. Therefore, retraction speed needs to be limited in the slicer to 40mm/s (Orbiter would be capable of 120mm/s). Otherwise, higher speed will lead to fake overcurrent detection and the driver will be disabled = extruder magically stops."

The orbiter has a estep value of 690, my Sprite SE is 420-something. Maybe that's enough?
My FW retractions were set to 0.2mm@50mm/s. Dropping them to 0.2mm@30mm/s and rerunning the gcode that failed this morning.

[Egosumumbravir]

OK, tried the PiP Gecko again and it also locked up the extruder.
Then I downloaded and copy of latest Prusa Slicer and ran the same PiP Gecko in that. It printed to completion, but it worth noting that in my haste and struggling to find the relevant sections, the speed & acceleration settings were not what I use in Orca so the print time was 2.5hrs instead of 1.5.

Since my existing FW is a couple of months old (20230904), I've spent this morning configuring, documenting and compiling latest firmware version (20240122).
Am just running a MPC tune now (I forgot to copy the previously determined values into the config file, whoops) and we'll see what we get in an hour or two.

[Egosumumbravir]

And we have a result: freshly compiled 20240122 with LA enabled and the extruder locks up again.
Recompile with everything else the same, LA disabled and the print with a 100% failure rate so far goes on to complete, if a little less clean than expected.

Reading around, and it certainly seems to be a somewhat documented bug in several places
Here (MRiscoC) as "[BUG] Extruder stops after some time with LA firmware #999" #999
Here (Marlin) as "[BUG] Extruder stops during print (Bugfix-2.0.x) #17944" MarlinFirmware/Marlin#17944
Here (Klipper) as "TMC2208 extruder driver shuts itself off in spreadcycle mode with pressure advance enabled #1774" Klipper3d/klipper#1774
Here on stack exchange https://3dprinting.stackexchange.com/questions/15564/extruder-motor-does-spin-but-not-while-printing
And a number of times through reddit where the Creality scattergun approach to manufacturing is considered to be a severe issue ( https://www.reddit.com/r/ender3/comments/mhahoc/the_mystery_of_the_linear_advance_lottery_of_the/ ) and the hacky solution is breaking out the soldering iron: https://drive.google.com/file/d/1oUj07YvqexBF21gjLlnnvFgyJlPtkhSL/view

My feeling now is that this issue isn't quite as fixed as thought. I'm unsure as to why firmware retractions seems to be linked, but layer height and printing speed also appear to heavily contribute - more typical Ender speeds and/or thicker layers reduces it's occurrence - I can do a 0.25mm layer 18 minute benchy, but a 2 hour 0.12mm layer PiP Gecko routinely trips the lockup bug.

It appears there's three potential solutions:

1. soldering iron to enable UART mode on the Creality board so I can switch the 2208 into spreadcycle.
2. Replace the board entirely with something not built down to the cheapest possible price (A BigTreeTech SKR Mini E3 appears to fit this bill with UART mode 2209 drivers). Might even be faster with more stepper torque from spreadcycle.
3. Klipperise the sucker. Darn, I was looking forwards to getting most of the Klipper speed and quality with this firmware.

[evilDave]

Hey, is anyone else still experiencing this issue? I had it a couple of times months ago (where I think it might have been actual over current due to having set E accel too high), and never since, until yesterday and it has happened 3 times in the last day. Different prints, did not see any error messages. I've turned octoprint serial logging on and SD card logging to see if anything turns up in there if/when it happens again.

The print that it just failed on looks fine right up until the point where it stopped, where there is a rough line that indicates to me "underextrusion" - but that can be explained by happening after the extruder stopped not before - zero extrusion is quite a bit "under".

(sorry about the delete and re-post: I am incapable of checking who I am logged in as before posting...)

[Egosumumbravir]

Hey, is anyone else still experiencing this issue?

The only solutions I came up with for preventing involved compiling without LA or printing thick and slow - fast fine layers seemed to trigger it more often than slow thick layers. So I ordered a BTT SKR Mini E3 v3 board and then that turned into a Klipper build so ... yeah it doesn't happen any more for me.