Extruder stops working randomly

[matthewwong212]

Occasionally, the extruder will just stop working. It's not a slicer issue, as I've tried with gcode files that I've used in the past. The extruder doesn't even attempt to turn.

I've verified that the extruder itself works, when purging filament through the filament menu or under move, it spits out filament just fine, but there's just no extrusion during the print itself.

I can't quite seem to reproduce it, it just seems to happen randomly.

To fix, I have to restore settings to default. If I restore to default, then load previous settings, it's still broken. But if I restore to default, store, then manually input all the same settings, then store, it works.

On the latest version of the firmware: 20220527

[mriscoc]

I didn't have that behavior but there is a function that avoids extrusion if the temperature is lower of certain limit. Check in Advanced / Filament Settings.

[matthewwong212]

doh, that might be it, I thought that setting only applied to the filament change/load/unload function

[p3num8ra]

I have also been having this issue, where the extruder stops moving.

The 'Extruder Min Temp' is set at 180 degrees, but I haven't seen the extruder temperature go that far down

Would this have anything to do with the Runout feature?

[mriscoc]

Would this have anything to do with the Runout feature?

When the printer detects a filament runout wait for the runout distance and then execute the Advanced pause feature.

[mriscoc]

No more feedback

[TheWebMachine]

I hate to reopen this old issue, but I started randomly having this happen, too. In my case, the extruder keeps stopping on the second layer. Just started happening last night.

It's a large flat sign. First layer goes down fine. Second layer starts printing, it gets about 2-3 moves in, then the extruder slows, jitters, then just stops complete and never spins again.

At first, I thought maybe I had a clog due to weak grip on the filament, but purging and retensioning the extrusion screw but everything seemed fine.

I started the same print again, same issue, same point in the print, extruder glitches out and stops. I have the same extruder temp limit of 180 set but never see temps drop that far. I do have a 240/85 first layer and 250/90 second layer temp set in the print, but all of my prints have had similar first layer temp differences regardless of filament type.

I'm going to try a print that did succeed yesterday before this issue popped up to confirm it isn't something in my gcode. I didn't see this mentioned above, but I am using octoprint. I will also try direct print via SD card, without octoprint, as well.

Failing all of that, I will attempt factory reset and reconfigure.

Is there anything else I can look at to help track this down? Perhaps the serial log from octoprint will show something useful, but I doubt it.

[mriscoc]

I hate to reopen this old issue, but I started randomly having this happen, too. In my case, the extruder keeps stopping on the second layer. Just started happening last night.

This g-code was pre-sliced for Ender 3V2: https://github.com/mriscoc/Ender3V2S1/blob/Ender3V2S1-Released/slicer%20scripts/cura/SimpleCuraTest.gcode You can use it for testing purposes.

[TheWebMachine]

I'm moving my current failing print from octoprint to the SD, disconnecting the cable, and trying again to see if source matters.

If also give that test gcode a try. I already downloaded it to test out the preview image, but remembered it doesn't work on DACAI screens.

[TheWebMachine]

So, moving the exact same failing gcode file from octoprint to the SD card resolved the extruder issue on layer 2. I'm going to move back to octoprint after this print finishes and try there again. I'll capture the full serial log to file this time.

I also realized I have rather long USB cable between the Pi and the printer and we are trying to passively push legacy 250kbps serial over it. I'm going to do one octoprint attempt with the existing cable length, then I'm going to switch over to a shorter length and/or usb3 connection to active hub (I'd have to rearrange to bring pi closer for shorter cable). Maybe excess cable length across the USB2 lines at that high speed is resulting is partly garbled or truncated commands.

[TheWebMachine]

I figured it out while digging through the serial log and comparing to original gcode for diffs! It was OctoLapse. The included OLapse Ender 3 profile doesn't jive with this firmware without modification. I suspect it is because in this firmware G90/G91 affects extruder and the default OLapse Ender 3 profile presumes Creality original firmware which perhaps doesn't.

It explains the issue. The X/Y/Z plods along fine but OLapse switches to absolute E on layer change (even if you are using non-move triggers), which causes the extruder to jitter like I saw because it was moving to absolute positions instead of relative extrude. OLapse wasn't switching E back to relative at the end of its code insertion on layer change.

This might explain the previous reporter's issue, too, if they were using OLapse. I think the fix here is to customize the OLapse Printer profile and ensure setting G90/G91 Influences Extruder = True (is False in default Ender 3 profile for whatever reason).

I didn't see a section in the Octoprint page of wiki for OctoLapse. Given its popularity, it might be prudent to include at least the proper printer profile details for OLapse in the wiki, as that should be the only thing that is firmware dependent beyond OLapse defaults.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.